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FOREWORD 

Managing  Joint  Service  Programs  is  a  great  challenge  for  professionals  in  the  field  of 
acquisition  in  the  80’s.  Effective  joint  program  management  necessitates  an 
understanding  of  each  of  the  services’  missions  and  operational  needs  as  well  as  the 
differences  in  their  acquisition  approaches.  Amalgamating  the  system  acquisition  needs 
of  two  or  more  military  services  under  the  charter  of  a  Joint  Program  Office  and 
successfully  delivering  the  system  on  time  and  within  budget  requires  exceptional 
managerial  skills. 

The  Joint  Logistics  Commanders  have  sponsored  this  guide,  as  an  aid  to  understanding 
Joint  Service  Program  Management.  The  acquisition  field  has  always  been  dynamic. 
Recent  enactment  of  Public  Law  99-348  which  created  the  Office  of  the  Under 
Secretary  of  Defense  for  Acquisition  is  an  example.  Accordingly,  this  guide  will 
continue  to  require  periodic  updating  and  the  Commandant,  Defense  Systems 
Management  College  has  assumed  this  responsibility.  Proposed  changes  or  additions  to 
»  this  guide  should  be  forwarded  to:  Commandant,  Defense  Systems  Management  College, 
Attn:  Research  Directorate,  Fort  Belvoir, Virginia  22060-5426. 
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PREFACE 


The  continuing  evolution  and  restruc¬ 
turing  of  the  Department  of  Defense 
(DoD)  acquisition  domain  dictate  the 
need  for  periodically  updating  this 
guide.  Accordingly,  this  third  edition  of 
the  guide  updates  the  references  to 
DoD,  JLC,  and  service  guidance  per¬ 
taining  to  or  relevant  to  the  management 
of  Joint  Service  Programs. 

This  update  of  the  guide  was  prepared 
under  the  sponsorship  of  the  Joint  Lo¬ 
gistics  Commanders  and  the  auspices  of 
the  Research  Directorate,  Defense  Sys¬ 
tems  Management  College.  The  guide’s 
goal  is  to  provide  newly  assigned  man¬ 
agers  of  joint  programs  and  their  staffs 
with  an  understanding  of  the  nature  of 
joint  programs,  how  they  differ  from 
single-service  programs,  and  which  as¬ 
pects  of  program  management  demand 
greater  emphasis  than  normally  accorded 
single-service  programs.  This  revision 
includes  two  additional  chapters;  one 
pertaining  to  security  and  the  other  to 
successful  programs  and  lessons  learned. 
The  guide  also  contains  a  number  of  ap¬ 
pendices  of  relevant  material  including  a 
listing  of  joint  service  programs.  The 
guide  is  limited  to  US  multiservice  pro¬ 
grams.  Further,  it  is  assumed  that  the 
reader  is  trained  or  experienced  in  the 
field  of  military  systems  acquisition 
management. 


Information  and  data  for  this  guide  up¬ 
date  were  provided  by  numerous  per¬ 
sonnel  and  sources  throughout  the  DoD 
and  other  sources.  In  addition,  special 
recognition  is  given  to  Cdr.  Lawrence 
M.  Kost,  USN,  Professor  of  Acquisition 
Management,  Defense  Systems  Manage¬ 
ment  College  (DSMC),  for  the  generous 
amounts  of  time  he  contributed  to  the 
reviews  of  this  guide  during  its  devel¬ 
opment.  Likewise,  the  review  efforts  of 
numerous  other  DSMC  staff  members 
are  also  acknowledged,  as  are  the  coor¬ 
dinating  efforts  of  the  JLC  Secretariats. 

The  appendices  contain  examples  of 
pertinent  references,  a  listing  of  Joint 
Service  Programs,  and  a  glossary  which 
primarily  contains  terms  and  definitions 
applicable  to  Joint  Programs. 

Due  to  the  dynamic  environment  of  the 
acquisition  field,  readers  are  cautioned 
to  verify  the  currency  of  the  directives, 
instructions  and  other  references  cited 
throughout  this  guide  prior  to  use  in 
actual  practice. 
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CHAPTER  1. 
INTRODUCTION 


"■h 


1.0  PURPOSE 

The  purpose  of  this  guide  is  to  provide 
a  reference  document  that  facilitates  a 
better  understanding  of  the  nature  of 
joint  acquisition  programs  and  how  joint 
programs  differ  from  single  service  pro¬ 
grams.  Aspects  of  program  management 
that  demand  greater  emphasis  than  sin¬ 
gle-service  acquisition  programs  are 
discussed  to  provide  an  appreciation  of 
the  increased  complexities  resulting  from 
the  intricacies  of  multiservice  involve¬ 
ment. 

Specific  areas  of  joint  service  program 
management  are  discussed  in  chapters  2 
through  11,  beginning  with  the  estab¬ 
lishment  of  a  joint  program  (Chapter  2) 
to  the  importance  of  security  (Chapter 
11).  Chapter  12  presents  a  discussion  of 
current  changes  in  the  field  of  DoD  ac¬ 
quisition  that  may  have  substantive  im¬ 
pacts  on  joint  program  management  in 
the  future.  The  last  chapter  discusses 
lessons  learned  and  highlights  a  selection 
of  successful  programs  based  on  inter¬ 
views  with  former  and  current  Program 
Managers  (PMs)  of  Joint  Service  Pro¬ 
grams.  The  guide  also  contains  six  ap¬ 
pendices,  three  of  which  provide  actual 
examples  of  currently  effective  Memo¬ 
randums  of  Agreement  (MOAs)  and  a 
program  charter.  (Appendices  A 
through  C.)  Appendix  D  provides 
guidance  for  the  preparation  of  a  Joint 
Integrated  Logistics  Support  Plan 
(JILSP).  Terms  and  definitions  which 
are  primarily  applicable  to  Joint  Pro¬ 
grams  are  provided  in  Appendix  E.  The 
final  appendix  (Appendix  F)  lists  joint 
acquisition  programs  that  are  currently 
operational. 

2.0  USAGE  OF  TERMS 

For  consistency  and  to  preclude  a  cer¬ 
tain  amount  of  redundancy,  the  term 
"lead  service"  is  primarily  used  through¬ 


fying  the  services  involved  in  a  joint 
program  as  the  "lead  and  rticipating 
services,"  in  all  cases,  ,ie  term 
"participating  services"  is  used  generi- 
cally  in  certain  instances.  Also,  the 
term  "material"  is  used  rather  than 
"materiel."  Exceptions  to  the  above  will 
occur  when  referenced  material  is 
quoted  or  reproduced  as  in  the  case  of 
Appendix  A. 

3.0  VARIATIONS  OF  JOINT  PRO¬ 
GRAMS 

A  variety  of  Joint  Service  Programs 
have  evolved  over  the  years  to  accom¬ 
modate  the  specific  needs  or  approaches 
directed  or  recommended  by  the  OSD, 
JCS,  JLC  or  participating  services.  For 
reference  purposes,  the  different  ap¬ 
proaches  have  been  categorized  as  pre¬ 
sented  in  Table  1-1.  The  categories 
range  from  a  program  that  is  basically  a 
single-service  program  with  other  ser¬ 
vices  indicating  interest  in  utilizing  the 
end  product  (see  S-2  in  Table  1-1),  to 
the  multiservice  involvement  of  a  fully 
integrated  Joint  Program  Office  (see  S-6 
in  Table  1-1).  In  addition,  the  cate¬ 
gories  also  include  other  varieties  of 
management  structures  such  as  those 
coded  M-l  through  M-4. 

The  selection  of  management  and  orga¬ 
nizational  approaches  for  a  proposed 
joint  program  should  be  based  on  con¬ 
siderations  of  how  best  to  achieve  the 
program’s  goals.  Approaches  are  not 
restricted  to  those  cited  in  Table  ,1-1. 
These  categories  are  based  on  historical 
data  and  may  not  reflect  the  current  ac¬ 
quisition  environment  of  a  proposed  new 
program,  Further,  various  aspects  of  a 
program,  such  as  its  urgency,  impor¬ 
tance,  size,  costs  and  other  factors  that 
may  influence  its  visibility,  may  affect  a 
joint  program  and  how  it  does  business. 
A  joint  cruise  missile  program,  for  ex¬ 
ample,  will  be  different  from  a  joint 
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out  the  guide  instead  of  "executive  ser¬ 
vice."  In  addition,  rather  than  identi¬ 


prograin  for  the  acquisition  of  a  mobile 
electric  power  portable  generator.  In 
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TABLE  1-1  JOINT  PROGRAM  CATEGORIES  AND  CHARACTERISTICS 


Program  Category 


Characteristic* 


S-T  Soo  note  below 

S-2  Single-service 

Manager  (Executive 
Agent) 

S-3  Single- service  PMO 
with  Point  of  Contact 

S-4  Single-service  PMO 
with  On-Site  Lieison 

S-5  Single-service  PMu 
with  Senior 
Representative 

S-6  Fully  Integrated  Joint 
Program  Office  (JPO) 


M-1  Lead-Service 

Cooroinated  Programs 

M-?  OSD  Directed 
Programs 


M-3  Confederated 
Programs 


M-4  Single-service 

Requirement— Other 
Service  Tasking 


Single-service  program;  interest  from  other  eervice(s)  manifested  by  their 
consumption  or  use  of  end  product;  all  program  direction  and  funding  has 
single  source 

Single-service  program;  interest  from  other  service(s)  manifested  by  thoi' 
designation  of  a  service  point  of  contact  (POC)  for  maintaining  liaison 

Singie-servica  program;  interest  from  other  service(s)  .manifested  by  their 
assignment  of  a  full-time  (PCS)  liaison  officer 

Single-service  program;  representative!*)  from  other  aervice(a)  assigned  to 
PMO;  all  authority  and  responsibility  to  program  manager  atoms  from  parent 
service,  no  formal  coordination  of  raqulrements.  charter,  etc. 

Multiaarvice  participation,  intagrated  JPO.  staffed  by  all  participating  ser¬ 
vices,  directed  by  program  manager  assigned  by  lead  service.  Participating 
aervicei  may  perform  tome  program  functions,  but  on  behalf  of  JPO.  not  for 
separate  service  program.  MODEL  JPO 

Program*  exist  in  more  than  one  service;  one  service  PMO  provides  coordinat 
ing  among  all  programs;  Executive  authority  does  not  reside  with  coordinat¬ 
ing  PMO 

More  than  one  service  has  program  in  the  technical  discipline.  A  lead  service 
is  not  assigned.  The  objectives  of  the  programs  may  not  be  the  same.  Direc¬ 
tion,  coordinetion  and/or  standardization  is  executed  not  through  a  desig¬ 
nated  leed  service,  but  by  the  OSD.  either  directly,  or  through  a  PMO  est¬ 
ablished  for  the  purpose  and  reporting,  not  to  a  military  service  acquisition 
commander,  but  the  OSD 

More  than  ona  service  has  st  least  one  program  in  the  generic  technical  area 
and  the  end  producls  of  which  are  used  in  allied  but  separate  warfare  areas. 
The  PMO*  characteristically  share  technical  information  and  development 

data 

Single-service  has  specific  requirement,  but  acknowledging  that  another 
service  has  preeminent  capability  or  interest  in  execution  of  a  part  of  the 
program  objective,  arranges  for  that  segment  to  be  executed  by  the  other 


Note:  A  Program  Designator  Code  of  S-1  denotes  a  single-service  program  and  accordingly  is  not  included  in 
the  table. 


addition,  in  the  course  of  an  acquisition 
program,  management  or  organizational 
approaches  may  need  to  evolve  from  one 
category  to  another  over  the  years  due 
to  a  number  of  circumstances,  such  as 
increased  top-level  interest,  revised 
mission  priorities,  funding  allocation 
changes,  etc. 

4.0  JOINT  SERVICE  GUIDANCE 

O'er  the  years,  through  the  cooperative 
efforts  of  the  services,  policy  and  pro¬ 
cedural  guidance  on  joint  program 
management  has  been  developed  and 
published  as  joint  service  documents. 
The  documents  generally  treat  a  specific 
area  of  joint  program  management  in 
detail.  The  documents  are  listed  in 
Table  1-2. 

5.0  ACQUISITION  PROGRAM  MAN¬ 
AGEMENT  GUIDANCE 

A  number  of  single  service  program 
management  guides  or  handbooks  have 
been  developed  that  can  be  beneficial  to 
involved  participating  service  personnel 
and  to  lead  service  personnel  as  aides  in 
understanding  participating  services’  ac¬ 
quisition  procedures.  Also,  the  Defense 
Systems  Management  College  (DSMC) 
has  published  a  program  manager’s 
notebook.  See  Table  1-3  for  a  listing  of 
the  guides  and  notebooks. 


TABLE  1-2  JOINT  SERVICE  PROGRAM  MANAGEMENT  DOCUMENTS 


DESIGNATION 


TITLE 


ARMY 


Configuration  Management 


Intcrservice  formal  School 
Training 


Joint  Daaign  to  Coat  Guide 


Management  of  Multi-  Service 
Syatamt.  Program*,  and  Project* 


Management  And  Execution 
of  Intagratod  Logiatic 
Support  {ILS}  Programs  For 
Muitiservice  Acquisitions 


Joint  Service  Automatic  Testing 
Acquisition  Planning  Guide 


Built-in-Test  Design  Guide 


Joint  Service  Weapon  System 
Acquisition  Review  Guidelines 
for  Automatic  Testing  (AT) 


Selection  Guide  for  Digital  Test 
Program  Generation  System* 


A  R  70-37 


AR  3B1-B 


AMC  P  700-6 


AMCR  69 


AR  700-129 


AMC  P  700-1 9 


AMC  P  34-1 


AMC  P  70-10 


AMC  P  70-9 


NAVY 


SECNAVINSt  4130.2 


NONE 


NONE 


NAVMATINST  6000. 1 0A 


OPNAVINST  4105.2 


NAVMAT  P-9404 


NAVMAT  P  8405 


NAVMAT  P-9406 


AIR  FORCE 


AFR  66-3 


AFR  60-18 


AFLCP/AFSCP  800-19 


AFSC/AFLC  R  800-2 


AFR  800-43 


AFSCP/AFLCP  800-38 


AFLCP/AFSCP  BOO-39 


AFLCP/AFSCP  800-40 


MARINE  CORPS 


SECNAVINST  4130 


NONE 


NONE 


NONE 


MCO  11310  86 


NAVMC-2719 


NAVMC-2721 


NAVMC  2720 


NAVMAT  P-9493 


AFLCP/AFSCP  800-41 


NAVMC-2718 


Inter  service  Depot  Maintenance 


AMCR  760-10 


NAVMATiniST  4790.21  A 


AFLCR/AFSCR  800- 3C 


TABLE  13  ACQUISITION  PROGRAM  MANAGEMENT  GUIDANCE 


SERVICE/ 

COMMAND 


DOCUMENT  TITLE  & 
(REFERENCE  NUMBER) 


REQUEST/ORDER  SOURCE 
&  NUMBER.  IF  APPLICABLE 


Air  Force  A  Guide  for  Program  Management 
(AFSC  P-800-3) 

Acquisition  Logistics  Management 
(AFLC/AFSC  P-800-34) 

Acquisition  Management  Illuminations 
for  System  Program  Offices 
(ASD  P-800-22) 


t  AFSC/DAPL 

|  Air  Force  Systems  Commend  (AFSC) 
Andrews  AFB,  20334-5000 
)  (Submit  Letter  Request) 

2750  ABW/DADA 

Wright-Patterson  AFB,  Ohio  45433-5001 
(Submit  Letter  Request) 


Materiel  Acquisition  Handbook 
(AMC/TRADOC  P-70-2) 


DTIC  (Assess  Number  to  be  Assigned) 


Best  Practices-How  to  Avoid  Surprises 
in  the  World's  Most  Complicated 
Technical  Process,  March  1986 
(NAVSO  P-6071) 

Nsvy  Program  Manager’s  Guide, 

1935  Edition  (NAVMAT  P-9494) 


GPO  Stock  No.  008-050-00234 


DTIC  ADA  151-925 


Marine  Corps  Project  Officers  Guidebook 


t‘c  4C  HQ  (Submit  Letter  Request) 


DSMC 


Acquisition  Strategy  Guide 


GPO  Stock  No.  008-020-01028-6 


DOD  Manufacturing  Management  Handbook  GPO  Stock  No.  008  020-01095  2 


Establishing  Competitive  Production 
Sources 

Integrated  Logistics  Support  Guide 

Introduction  to  DOD  Program  Management 
(Advance  Copy  -  April  1986) 

Risk  Assessment  Techniques 

Skill  in  Communication 

Strategies  for  Dealing  With  the 
Defense  Budget 

System  Engineering  management  Guide 
2nd  Edition,  December  1986 

The  Program  Manager’s  Notebook, 

October  1 985 

The  Warranty  Guide 


GPO  Stock  No.  008-020-01037-5 


GPO  Stock  No.  008-020-01081-2 

DSMC  (Deputy  Director,  Program 
Management  Course) 

GPO  Stock  No.  008-020-00963-9 

GPO  Stock  No.  008-020  01036  7 

DTIC  ADA  134-459 


GPO  Stock  No.  008-020-01099-5 


DTIC  ADA  176-002 


DTIC  A9A  170-448 
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CHAPTER  2 

JOINT  PROGRAM  INITIATION 


1.0  SYNOPSIS 

This  chapter  discusses  the  important  as¬ 
pects  of  establishing  joint  programs  for 
the  acquisition  of  defense  systems  and 
the  initiation  activities  involved.  Ratio¬ 
nale  for  the  establishment  of  joint  pro¬ 
grams  are  presented  in  section  2.0.  In 
section  3.0,  background  information  is 
provided  regarding  the  establishment  of 
joint  programs  in  recent  years,  including 
the  efforts  of  the  Joint  Requirements 
Oversight  Council  (JROC).  Section  1  0 
presents  a  summary  of  each  of  the  Ser¬ 
vices’  processes  and  procedures  for  the 
harmonization  of  requirements.  The 
process  of  initiating  joint  programs,  in- 
iding  Memorandums  of  Agreement 
(MOA),  are  discussed  in  section  5.0.  A 
discussion  about  the  preparation  of  Joint 
Program  Charters  is  presented  in  section 
6.0.  A  summary  of  the  chapter  is  pro¬ 
vided  in  section  7.0. 

2.0  JOINT  PROGRAM  INITIATION 
RATIONALE 

Joint  programs  for  the  acquisition  of 
detense  systems  should  be  carried  out 
efficiently  and  effectively  in  accordance 
with  DoDD  5000.1  of  12  March  1986 
and  DoDI  5000.2  of  12  March  1986.1/2/ 
Rationale  for  the  establishment  and  ini¬ 
tiation  of  a  joint  program  rather  than  a 
single  service  program  can  be  numerous 
and  vary  in  complexity.  Most  joint  pro¬ 
grams  are  primarily  instituted  for  either 
operational  or  economic  advantages,  or 
both.  Typically,  one  or  more  of  the 
following  factors  will  contribute  to  the 
decision  to  initiate  a  joint  program: 

•  Improvement  of  Combat  Capability 
Need,  Multiservice  weapon  system  en¬ 
hancement  may  be  needed  to  meet  a 
newly  identified  threat  or  to  respond  to 
a  modified  threat  that  requires  new 
measures  to  counter  't. 


•  Interoperability  of  Equipments.  In¬ 
terfaces,  especially  in  the  areas  of  com¬ 
mand  and  control,  communications,  and 
intelligence,  where  interdependence  of 
air,  ground,  and  naval  forces  necessitate 
joint  definition  and  central  control  of 
system  emphasize  the  need  for  joint  ac¬ 
quisition. 

•  Coordination  of  Efforts.  Coordi¬ 
nation  reduces  duplication  of  effort,  im¬ 
proves  exchange  of  technical  informa¬ 
tion,  and  channels  individual  service 
efforts  into  mutually  supporting  pro¬ 
grams. 

•  Reduction  in  Development  Costs. 
All  other  things  being  equal,  one  devel¬ 
opment  program  should  be  less  expen¬ 
sive  than  two,  If  the  requirements  of 
the  services  are  compatible,  and  consoli¬ 
dations  of  programs  does  not  increase 
risk  unduly  by  closing  out  alternatives, 
one  joint  program  should  be  more  cost 
effective  than  multiple,  single-service 
efforts. 

e  Reduction  in  Production  Costs. 
Consolidation  of  the  services’  production 
requirements  should  lower  unit  price 
through  savings  in  set  up  costs,  learning 
curve  impacts,  special  tooling,  and 
quantity  production  or  procurement  of 
unit  components. 

•  Reduction  in  Logistics  Require¬ 
ments.  Standardization  across  services 
offers  potential  for  both  reducing  sup¬ 
port  costs  and  improving  the  support 
provided  to  operating  forces. 

e  Multiservice  Application.  When 
certain  operational  needs  or  require¬ 
ments  are  similar,  such  as  in  the  case  of 
the  Army  and  the  Marine  Corps,  acqui¬ 
sition  should  be  by  joint  means. 
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3.0  ESTABLISHING  JOINT  PRO¬ 
GRAMS 


Joint  programs  can  and  should  be  estab¬ 
lished  through  agreements  between  two 
or  more  services  whenever  a  mutual  or 
similar  need  or  requirement  exists  as  in 
the  case  with  the  Air  Force  and  the 
Navy  establishing  the  Cobra  Judy  Radar 
Program.  In  the  past,  however,  con¬ 
gressional  interest  in  a  program  often 
prompted  the  Office  of  the  Secretary  of 
Defense  (OSD)  to  take  the  lead  in  estab¬ 
lishing  a  program  as  a  joint  effort,  such 
as  in  the  case  of  the  Copperhead  Pro¬ 
gram,  or  through  the  direction  of  OSD, 
as  in  the  case  of  Base  and  Installation 
Security  System  (BISS)  Program.  Like¬ 
wise,  influences  of  the  Joint  Chiefs  of 
Staff  (JCS)  or  ihe  Joint  Logistics  Com¬ 
manders  (JLC)  resulted  in  the  creation 
of  joint  programs  such  as  the  WWMCCS 
Information  System  (WIS)  Program  and 
the  Modular  Automated  Test  Equipment 
(MATE)  Program,  respectively.-’ 


In  March  1984,  the  Joint  Requirement* 
Oversight  Council  (JROC)  was  created 
by  charter  under  the  auspices  of  the 
Joint  Chiefs  of  Staff  (JCS)  to  promote 
and  facilitate  the  establishment  and  use 
of  joint  programs.  The  primary  respon¬ 
sibilities  of  the  JROC  are  to:  examine 
potential  joint  military  requirements; 
identify,  evaluate  and  select  candidates 
for  joint  development  and  acquisition 
programs;  provide  oversight  of  cross¬ 
service  requirements  and  management 
issues;  and  resolve  service  issues  that 
arise  after  a  joint  program  has  been  ini¬ 
tiated.  Permanent  members  of  the 
JROC  consist  of  the  Vice  Chiefs  of 
Staff  of  the  Air  Force  and  Army,  the 
Vice  Chief  of  Naval  Operations,  the 
Assistant  Commandant  ofthe  Marine 
Corps,  and  the  Director  of  the  Joint 
Staff.  As  deemed  appropriate  by  the 
Chairman,  JROC,  associate  members 
may  be  designated  for  each  meeting. 
The  JROC  chairmanship  is  totaled 
among  the  services. 


Since  its  inception,  the  JROC  has  initi¬ 
ated  the  establishment,  or  been  involved 
with  a  number  of  joint  programs,  such 
as  Cruise  Missile  Systems,  Reconnais¬ 
sance  Remotely  Piloted  Vehicles  (RPVs) 
and  their  payloads  and  data  links.  Elec¬ 
tronic  Warfare  Commonality/ Joint  Pro¬ 
grams,  Tactical  Military  Deception 
(TAC-D)  Systems,  the  MK.XV  Combat 
Identification  System  (CIS),  the  Space- 
Based  Radar/Infrared  (SBR/IR),  High 
Frequency  Anti-Jam  (HFAJ)  Commu¬ 
nication  Systems,  and  the  WWMCCS 
Information  System  (WIS). 

In  addition  to  the  above  activities,  the 
JROC  has  also  been  involved  in  identi¬ 
fying  joint  requirements  and  promoting 
a  joint  service  position  on  joint  program 
funding.  A  Memorandum  for  Record 
was  issued  in  August  1986  that  pre¬ 
sented  a  joint  service  position,  endorsed 
by  the  JROC,  regarding  the  preferred 
funding  arrangement  for  joint  programs. 
The  concept  for  joint  program  funding 
was  presented  as  follows:^ 

•  The  lead  Service,  particularly  on 
major  programs,  should  have  total  pro¬ 
gram  funding  authority  and  responsibil¬ 
ity.  Funding  arrangements  should  be 
agreed  to  as  early  in  the  acquisition 
process  as  possible. 

•  Each  participating  Service  should 
fund  its  own: 

-  Service  unique  integration  efforts 

-  Service  unique  improvements/ 
changes 

-  Service  procurement 

•  Programs  falling  under  this  concept 
must  have: 

-  a  firm  statement  of  requirements 

-  a  commitment  to  funding  (R&D  and 
procurement) 

-  a  detailed  MOA/MOU  covering 
funding,  management,  and  technical 
baselines. 
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Subsequently,  in  September  1986,  the 
JROC  issued  another  Memorandum  for 
Record  regarding  the  policy  and  proce¬ 
dures  for  joint  potential  review  and 
designation  of  programs  and  require¬ 
ments.^  The  memorandum  stated  that 
the  benefits  of  combined  efforts  among 
the  Services  in  development  and  acqui¬ 
sition  of  material  are  well  recognized. 
The  potential  cost  savings  associated 
with  quantity  buys  and  the  military  ad¬ 
vantages  of  interoperable/common 
equipment  on  the  battlefield  are  com¬ 
pelling  reasons  to  address  "jointness" 
with  even  greater  emphasis.  Although 
there  will  be  programs/requirements  in 
which  unique  Service  needs  will  pre¬ 
clude  joint  development  or  procurement, 
it  is  the  intent  of  the  JROC  that  each 
Service  implement  procedures  whereby 
programs/requirements  are  reviewed  to 
determine  the  potential  for  inter-Service 
cooperative  ventures.  The  elements  of 
the  policy  are: 

•  The  Services  are  responsible  for 
ensuring  that  this  review  is  performed. 

•  When  other  Services  are  requested 
to  comment  on  a  program/requirement, 
they  shall  respond  within  a  reasonable 
time  period. 

•  The  Services  are  responsible  for 
preparing  a  comprehensive  list  of  the 
programs/requirements  reviewed. 

•  The  Service  directors  of  R&D  shall 
meet  yearly  to  review  their  lists. 

•  These  lists  shall  be  forwarded  to  the 
JROC  with  a  certification  that  the  re¬ 
quired  review  has  been  accomplished 
and  with  a  "joint  potential"  designator 
assigned  to  each  program/requirement. 

•  These  procedures  shall  apply  to  all 
acquisition  categories  (I  through  iV). 

•  Technology  Base  programs  shall  be 
exempt  from  this  process. 


The  intent  of  the  policy  is  to  stimulate 
communications  among  the  Services,  and 
applies  to  all  new  Service  and  Unified 
and  Specified  Command  requirements 
documents,  as  well  as  all  R&D  programs 
approved  for  initiation  and  inclusion  in 
the  Services  Program  Objective  Memo¬ 
randums  (POMs),  and  all  programs  fac¬ 
ing  a  milestone  I  or  II  review  during 
Fiscal  Year  1987. 

The  joint  potential  review  and  designa¬ 
tion  process  encompasses  the  following 
actions: 

•  Each  Service  will,  when  appropri¬ 
ate,  solicit  the  other  Services’  comments 
on  the  joint  potential  of  each  new  R&D 
program  approved  for  initiation  and 
each  new  Service  requirement  document. 
When  comments  are  solicited,  response 
will  be  mandatory.  Unified  and  Speci¬ 
fied  Command  requirements  will  be  re¬ 
viewed  by  the  Joint  Staff  with  Service 
participation. 

a  Each  Service  will  be  individually 
responsible  for  assigning  a  joint  poten¬ 
tial  designator  to  each  require¬ 
ment/program.  The  Joint  Staff  will  as¬ 
sign  designators  for  Unified  and  Speci¬ 
fied  Command  requirements.  Designa¬ 
tion  will  be  in  accordance  with  the  fol¬ 
lowing  criteria. 

-  Independent.  Independent  programs 
and  requirements  are  those  in  which 
there  is  no  potential  for  other  Service 
use  or  joint  systems  development. 

-  Interoperating.  Interoperating  pro¬ 
grams  and  requirements  are  those  in 
which  joint  program  management  is  in¬ 
appropriate,  but  a  potential  for  joint 
operation  or  joint  systems  interface  ex¬ 
ists. 

-  Joint.  Joint  programs  and  require¬ 
ments  are  those  in  which  a  potential  for 
joint  R&D  program  management  and/or 
joint  procurement  exists. 


•  Annually,  each  Service  will  be  re¬ 
sponsible  for  preparing  a  Joint  Potential 
Designation  List  (JPDL)  of  all  new  pro¬ 
grams  and  previously  designated  pro¬ 
grams  facing  a  milestone  I  or  II  review 
during  the  next  fiscal  year.  The  Joint 
Staff  will  prepare  a  JPDL  for  Unified 
and  Specified  Command  requirements. 

•  These  lists  will  be  individually  and 
jointly  reviewed  by  the  directors  of 
R&D  in  each  Service  by  1  March  each 
year  for  completeness  and  the  appropri¬ 
ateness  of  the  designator  assigned  to 
each  program.  The  Secretary,  JROC, 
will  review  the  Unified  and  Specified 
Command  requirements  JPDL  and  will 
coordinate  the  scheduling  of  the  R&D 
directors’  review. 

•  No  later  than  April  each  year,  these 
lists  will  be  forwarded  by  each  Service 
director  of  R&D  to  the  JROC  Secre¬ 
tariat  for  JROC  review  either  as  in¬ 
book  items  or  as  items  for  specific  at¬ 
tention  based  upon  the  recommendations 
of  the  Service  directors  of  R&D  and/or 
the  Secretary,  JROC. 

•  Programs  receiving  initiation  ap¬ 
proval  after  the  JPDLs  have  been  for¬ 
warded  to  the  JROC  will  be  designated, 
jointly  reviewed,  and  referred  to  the 
JROC  within  90  days  of  Service  ap¬ 
proval. 

•  Completed  joint  potential  review 
and/or  designation  will  not  be  manda¬ 
tory  before  the  Services  can  fund  any 
given  program,  but  is  it  the  intent  of 
the  JROC  that  Service,  Military  De¬ 
partment,  and  DoD  formal  acquisition 
reviews  include  joint  potential  review 
designation  as  an  item  of  interest. 

4.0  HARMONIZATION  OF  RE¬ 
QUIREMENTS 

The  Services  involved  in  a  joint  acquisi¬ 
tion  should  follow  the  established  re¬ 
quirements  process  and  procedures  for 


the  harmonization  of  requirements  in 
order  tr  adjust  or  resolve  differences  or 
inconsistencies  and  thus  bring  significant 
features  into  agreement.  A  summary  of 
each  Service’s  requirements  process  and 
procedures  for  the  harmonization  of  re¬ 
quirements  are  presented  below: 

•  Air  Force 

Details  of  the  Air  Force  operational  re¬ 
quirements  process  are  delineated  in  the 
Air  Force  Regulation  (AFR)  57-1  of 
September  1987.  The  process  calls  for 
brief,  generalized  Statements  of  Opera¬ 
tional  Need  (SON),  the  delegation  of 
validation  authority  to  the  Major  Com¬ 
mands  (MAJCOMs),  a  corporate  review 
of  System  Operational  Requirements 
Documents  (SORDs)  prior  to  major 
milestones,  and  the  development  of  a 
Requirements  Correlation  Matrix 
(RCM).  Also  Depot  Support  Require¬ 
ments  Documents  (DSRDs)  will  be  di¬ 
rected  by  Program  Management  Direc¬ 
tives  (PMDs)  action. 

The  Directorate  of  Plans,  HQ 
USAF/XOX,  is  the  Office  of  Primary 
Responsibility  for  AFR  57-1. 

When  a  SON  is  prepared  by  the  user 
that  identifies  and  states  operational 
needs  in  mission  areas  shared  by  other 
Air  Force  MAJCOMs  or  Separate  Oper¬ 
ating  Agencies  (SOAs),  operating  com¬ 
mands  must  coordinate  with  those  orga¬ 
nizations.  Multi-command  SONs  are  to 
be  processed  by  the  lead  command  in 
the  same  manner  as  those  developed  by 
a  single  command.  Operational  com¬ 
mands  will  develop  SONs  in  close  coor¬ 
dination  with  the  implementing  com¬ 
mand  to  ensure  that  all  major  issues  are 
resolved  prior  to  validation.  Subse¬ 
quently,  the  SONs  will  be  forwarded  to 
HQ  USAF/XOXFQ  for  coordination, 
including  formal  coordination  with  other 
Services. 


The  operating  command  will  submit  a 
System  Operational  Requirements  Doc¬ 
ument  (SORD)  for  each  funded  program 
as  tasked  in  the  Program  Management 
Directive  (PMD).  The  SORD  is  the  re¬ 
quirements  and  planning  document  pre¬ 
pared  to  address  operational  and  support 
needs.  It  amplifies  and  refines  SON. 
Operational  commands  will  develop 
SORDs  in  close  coordination  with  im¬ 
plementing  commands  to  ensure  that  all 
major  issues  are  resolved  prior  to  SORD 
approval. 

For  programs  with  RDT&E  costs  greater 
than  $50  million  and/or  total  program 
costs  greater  than  $250  million  (FY80 
dollars),  the  SORD  will  be  reviewed  and 
approved  by  HQ  USAF/XOX.  Operat¬ 
ing  commands  retain  approval  authority 
below  these  thresholds. 

The  Requirements  Correlation  Matrix 
(RCM)  has  a  primary  purpose  to  docu¬ 
ment  and  track  the  formulation  of  and 
changes  to  user  requirements  as  they 
evolve  through  the  program  acquisition 
process.  The  RCM  is  a  mandatory  at¬ 
tachment  to  all  SONs  and  SORDs  as  di¬ 
rected  by  the  PMD. 

The  Depot  Support  Requirements  Doc¬ 
ument  (DSRD)  is  a  stand-alone  docu¬ 
ment  that  is  an  adjunct  to  and  comple¬ 
ments  the  SORD.  The  DSRD  describes 
the  supporting  command’s  plans  and  re¬ 
quirements  for  providing  both  mainte¬ 
nance  and  material  support  to  the  system 
described  in  the  SORD. 

Following  MAJCOM-level  review  and 
coordination,  DSRDs  wili  be  submitted 
to  HQ  USAF/LEYM  for  approval. 

In  addition,  HQ  USAF/XOX  harmonizes 
Air  Force  needs  with  other  Services  for 
purposes  of  applicability,  commonality, 
standardization  and  interoperability,  and 
also  ensures  that  other  service  requiie- 
ment  documents  receive  appropriate  Air 
Force  functional  review. 


•  Army 

The  Army’s  requirements  process  is  out¬ 
lined  in  AR  71-9,  Material  Objectives 
and  Requirements,  with  implementing 
instructions  in  AMC-TRADOC  pam¬ 
phlet  70-2,  Materiel  Acquisition  Hand¬ 
book.  Responsibility  for  requirements 
on  the  Army  Staff  falls  in  the  Force 
Development  Directorate  of  the  Office 
of  the  Deputy  Chief  of  Staff  for  Opera¬ 
tions  and  Plans  (ODCSOPS).  Although 
the  ODCSOPS  is  the  DA  staff  element 
responsible  for  requirements,  and  in  fact 
validates  most  requirements  in  the  Army 
process,  the  Army’s  Training  and  Doc¬ 
trine  Command  (TRADOC)  plays  a  very 
key  role. 

As  the  Army  combat  developer  and  user 
representative,  TRADOC,  is  responsible 
for  the  generation  and  staffing  of  Army 
requirements.  While  requirements  usu¬ 
ally  originate  in  one  of  the  TRADOC 
schools,  formal  world-wide  staffing  is 
the  purview  of  the  TRADOC  headquar¬ 
ters.  In  fact,  the  "harmonization  pro¬ 
cess,"  or  the  process  whereby  the  re¬ 
quirements  are  staffed  by  the  other  Ser¬ 
vices,  occurs  at  the  same  time  as  the 
staffing  by  major  Army  commands  and 
is  the  responsibility  of  TRADOC,  not 
the  Army  staff, 

One  major  difference  exists  between  the 
Army  and  Air  Force  processes  in  that 
the  Army  requirements  can  be  docu¬ 
mented  in  several  formats  as  compared 
to  a  single  one  of  the  Air  Force. 

•  Navy 

The  Navy’s  requirements  process  is  de¬ 
scribed  in  OPNAVINST  5000.42C  of  10 
May  1986.  The  Navy’s  process  is  man¬ 
aged  by  the  Director,  Research,  Devel¬ 
opment  and  Acquisition  (OP-098)  in  the 
Office  of  the  Chief  of  Naval  Operations. 
The  Navy’s  process,  having  undergone 
significant  change  in  1983,  differs  from 
ihe  process  of  the  other  Services. 


2-5 


\  ajv  , /v  i  rv  tyw  «  r\  m  j 


Program  initiation  begins  with  the  pro- 
mulgation  of  a  Tentative  Operational 
Requirement  (TOR).  The  TOR  is  then 
circulated  to  other  Services  for  harmo¬ 
nization  of  requirements.  In  response  to 
the  TOR,  a  Development  Options  Paper 
(DOP)  is  initiated  by  the  appropriate 
Systems  Command  (SYSCOM).  The 
DOP  will  address  a  range  of  alternatives, 
to  include  other  Services’  requirements, 
and  cost  trade-offs.  An  Operational 
Requirement  (OR)  is  develooed  by  the 
program  sponsor  after  examining  the 
options  presented  in  the  DOP. 

In  the  Navy  process  a  promulgated  OR 
is  required  before  a  program  will  be 
considered  for  POM  funding  but  does 
not  automatically  ensure  POM  funding 
when  submitted.  If  an  OR  is  not 
funded  it  will  be  reviewed  during  the 
following  year’s  POM  cycle.  Most  ORs 
are  sent  out  for  harmonization,  when 
approved,  whether  funded  or  not. 

•  Marine  Corps 

The  Marine  Corps  requirements  process 
is  described  in  MCO  3900.4C,  MCO 
5000.15,  and  MCO  P5000.10A.  The 
Marine  Corps,  limited  in  both  RDT&E 
funding  and  management  resources, 
must  depend  on  or  work  jointly  with  the 
other  Services  to  satisfy  many  of  its  re¬ 
quirements. 

The  Marine  Corps  requirement  docu¬ 
ments  are  prepared  by  the  Marine  Corps 
Development  and  Education  Command 
(MCDEC).  The  requirement  is  initially 
represented  in  a  Justification  for  a  Ma¬ 
jor  System  New  Start  (JMSNS)  or,  for  a 
less  than  major  system,  a  Justification 
for  System  New  Start  (JSNS).  Once  the 
JMSNS/JSNS  is  approved  and  validated 
by  Headquarters  Marine  Corps  (HQMC), 
a  Required  Operational  Capability 
(ROC)  is  published  which  describes  the 
requirement  in  more  detail.  These  doc¬ 
uments  (JMSNS/JSNS/ROC)  are  pre¬ 
pared  in  draft  form  and  distributed  to 


the  other  Services  so  that  their  com¬ 
ments  can  be  reviewed  prior  to  docu¬ 
ment  approval. 

An  example  of  how  the  harmonization 
issue  is  addressed  at  the  OSD  level  may 
be  seen  in  the  functioning  of  the  Ar¬ 
mament/Munitions  Requirements,  Ac¬ 
quisition  and  Development  (AMRAD) 
Committee.  The  mission  of  the  AM¬ 
RAD  Committee  is  to  assist  OSD  level 
offices,  JCS,  Military  Departments  and 
other  DoD  components  in  developing 
harmonized  requirements  which  fulfill 
multiservice  munitions  and  related  sub¬ 
system  needs.  The  committee  is  com¬ 
posed  of  senior  members  from  each  ser¬ 
vice  and  they  act  in  an  advisory  capacity 
to  promote  effective  and  efficient 
munitions  acquisition. 

5.0  JOINT  PROGRAM  INITIATION 

Although  each  joint  program  is  unique 
in  that  it  addresses  a  particular  set  of 
requirements  subject  to  various  opera¬ 
tional,  fiscal  and  political  constraints,  all 
joint  programs  are  initiated  through 
similar  processes,  such  as  those  discussed 
in  section  3.0  above  as  well  as  the  fol¬ 
lowing: 

•  Determining  that  a  common  or  re¬ 
lated  set  of  requirements  exists  among 
two  or  more  services  and/or  that  the  re¬ 
quirements  could  be  most  cost  effec¬ 
tively  achieved  through  a  joint  program. 
This  normally  occurs  during  the  review 
of  a  "Justification  for  Major  System 
New  Start  (JMSNS)"  in  the  major  system 
acquisition  process,  or  a  comparable  but 
less  formalized  vehicle  in  less  than  ma¬ 
jor  systems  acquisitions,  e.g.,  during  a 
budget  review  or  in  reviews  of  Joint 
Operational  Requirements  (JORs).  For 
major  systems  acquisitions,  this  decision 
is  normally  documented  in  a  Secretary 
of  Defense  Decision  Memorandum, 
(SDDM),  which  specifies  the  lead  DoD 
component  and  provides  explicit  guid- 
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ance  regarding  the  responsibilities  of  the 
participating  services. 

•  Within  the  context  of  the  OSD 
guidance,  participants  in  a  joint  program 
negotiate  specific  roles,  activities,  re¬ 
sponsibilities,  and  fiscal  support  to  be 
provided  by  the  lead  and  participating 
services. 

•  When  successfully  concluded,  these 
negotiations  will  result  in  one  or  more 
Memorandum  of  Agreement  (MOA) 
between  the  participating  and  lead  ser¬ 
vices.  A  well  developed  MOA  is  highly 
essential  to  the  success  of  any  joint  pro¬ 
gram,  particularly  the  agreements  on  re¬ 
quirements  and  funding  (see  Appendix 
A).^  When  agreement  is  reached  at  ei¬ 
ther  the  service  headquarters  or  secre¬ 
tariat  level,  it  is  usually  documented  by 
an  MOA.  There  is  no  typical  content  or 
format  for  an  MOA.  It  may  be  a  long 
document,  defining  all  the  ground  rules 
for  the  joint  program  or  it  may  be  very 
brief,  covering  only  key  areas  of  agree¬ 
ment,  such  as  designation  of  the  lead 
service  and  sharing  of  funding  responsi¬ 
bility.  Frequently,  a  program  will  have 
several  MOAs,  each  covering  a  different 
topic.  Additional  negotiations  and  pro¬ 
gram  definition  activities  can  subse¬ 
quently  lead  to  the  Joint  Program  Man¬ 
ager’s  Charter.  The  charter,  when  pro¬ 
mulgated,  becomes  the  foundation  for 
the  joint  program.  It  formally  estab¬ 
lishes  the  program  and  announces  to  all 
concerned  the  responsibilities  and  in¬ 
tended  relationships  among  the  partici¬ 
pating  services.  Appendix  B  contains  a 
Joint  Program  Manager’s  Charter  for  the 
V-22  OSPREY  Program. 

•  The  implementation  of  OSD  direc¬ 
tion  is  different  in  each  of  the  services. 
The  Army  and  Navy  simply  forward  by 
memorandum  USD(A)  direction  to  the 
appropriate  development  and  acquisition 
activity  via  the  chain  of  command.  In 
the  Air  Force,  HQ  USAF  directs  major 
command  participation,  either  as  lead  or 


supporting  elements,  via  Program  Man 
agement  Directives  (PMD).  Further  de¬ 
lineation  of  participation  below  major 
command  level  is  promulgated  by  Form 
56  within  AFSC,  and  Program  Action 
Directive  (PAD)  within  AFLC. 

•  Interservice  negotiations  and  agree¬ 
ments  on  joint  programs  can  be  accom¬ 
plished  at  any  of  several  echelon  in  the 
services’  organizational  hierarchies:  the 
service  secretariats,  the  service  head¬ 
quarters,  the  material  development  and 
logistics  commands,  or  their  commodity- 
oriented  commands.  However,  excep¬ 
tions  do  occur,  for  example,  the  Com¬ 
manders  of  the  Naval  Air  Systems 
Command  and  the  Air  Force  Systems 
Command  have  agreements  on  acquisi¬ 
tion  of  air-to-air  missiles. 

If  there  is  a  general  rule,  it  is  to  agree 
that  the  lowest  level  agreement  is  prac¬ 
ticable,  with  the  understanding  that  the 
level  will  vary  from  program  to  pro¬ 
gram.  However,  there  are  two  advan¬ 
tages  to  agreements  at  the  service  head¬ 
quarters  level:  (1)  it  is  the  level  at  which 
operational  requirements  are  validated 
and  translated  into  equipment  needs,  and 
(2)  it  is  the  level  at  which  funding  pri¬ 
orities  are  established.-^ 

6.0  JOINT  PROGRAM  CHARTERS 

Preparation  of  the  Program  Manager’s 
Charter.  An  interim  charter,  setting 
forth  a  basic  set  of  ground  rules  under 
which  the  Program  Manager  and  par¬ 
ticipating  services  will  operate  prior  to 
promulgation  of  the  formal  Program 
Manager’s  Charter,  may  be  issued  by 
OSD  or  by  the  cognizant  Command 
within  the  lead  service.  The  preparation 
of  the  final  charter  is  normally  the  re¬ 
sponsibility  of  the  lead  service,  subject 
to  negotiations  with  the  participating 
services.  The  designated  lead  service 
Program  Manager  is  usually  responsible 
for  developing  the  charter,  with  the  as¬ 
sistance  and  concurrence  of  the  partici- 
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pating  services.  In  a  few  instances,  OSD 
has  promulgated  the  charter  for  joint 
programs  in  which  they  were  particu¬ 
larly  interested.  Even  if  an  MOA  has 
been  signed  and  there  is  no  formal  re¬ 
quirement  to  gain  concurrence  from  the 
other  services,  it  is  in  the  best  interest 
of  the  Program  Manager  (PM)  and  the 
program,  to  staff  the  charter  with  the 
participating  services. 

If  OSD  retains  approval  authority,  the 
lead  service  is  responsible  for  the  sub¬ 
mission  of  the  charter.  There  are  two 
ways  the  charter  can  be  submitted: 

First,  if  OSD  specifies  that  the  charter 
be  submitted  through  the  JCS,  the 
charter  should  be  submitted  by  the  ser¬ 
vice  chief  to  the  JCS  and  a  joint  action 
initiated  to  gain  a  JCS  recommendation 
for  OSD.  Once  the  joint  action  is 
started,  the  responsibility  for  the  action 
lies  with  the  joint  action  officer  and  the 
lead  service  reverts  to  being  a  voting 
member  with  the  same  status  as  the 
other  services.  Also,  the  services  that 
may  not  be  a  party  to  the  program  are 
involved  and  will  vote  on  the  charter  in 
the  joint  action.  Second,  if  there  is  no 
requirement  for  a  JCS  recommendation, 
the  charter  will  more  than  likely  be 
submitted  to  OSD  by  the  service  secre¬ 
tary. 

Promulgation  of  the  Charter.  For  less- 
than-major  system  acquisitions,  the 
charter  is  normally  promulgated  by  the 
material  or  logistic  Command  within  the 
lead  service.  Major  acquisition  charters 
are  promulgated  at  higher  echelons 
within  the  lead  service,  such  as  the 
Secretary  of  the  Army,  the  Navy  Ac¬ 
quisition  Executive,  and  the  cognizant 
Air  Force  Chief  of  Staff.  Although  the 
JLC  "Memorandum  of  Agreement  - 
Management  of  Multiservice  Sys- 
tems/Programs/Projects"  (Appendix  A) 
calls  for  joint  approval  of  Joint  Pro¬ 
gram/Project  Manager’s  Charters,  such 
jointly-signed  charters  are  rare. 


Establishing  the  Program  Manager’s 
Authority.  While  a  charter  cannot 
guarantee  that  the  joint  program  man¬ 
ager  will  have  authority  commensurate 
with  his  responsibilities,  care  should  be 
taken  to  ensure,  that  the  charter  gives 
him  the  authority  needed  to  manage, 
rather  than  merely  to  coordinate  the 
joint  program.  Specifically,  the  Program 
Manager  must  have  adequate  authority 
to: 

•  make  trade-offs  between  cost, 
schedule,  supportability  and  perfor¬ 
mance  within  bounds  established  for  the 
program, 

•  identify  program  funding  needs  and 
to  control  funds  allocated  to  the  pro¬ 
gram, 

9  determine  and  control  hardware  and 
software  configuration, 

•  communicate  directly  with  other 
services  and  Government  agencies,  and 

•  manage  his  military  and  civilian 
staff. 

Attributes  of  an  Effective  Joint  Program 
Charter.®^  Joint  programs  are  excep¬ 
tions  to  the  services’  normal  acquisition 
practices.  Thus,  the  Joint  Program 
Charter  must  include  those  elements  es¬ 
sential  to  any  charter  and  those  needed 
to  define  specific  relationships  among 
the  participating  services.  The  extent  to 
which  the  latter  must  be  defined  in  the 
charter  depends  on  the  circumstances 
surrounding  establishment  of  the  joint 
program.  If,  at  the  inauguration 'of  a 
joint  program,  there  exists  a  major  issue 
involving  responsibility,  authority,  or 
interservice  relationships,  it  should  be 
resolved  in  the  charter  to  preclude  fu¬ 
ture  problems.  The  following  items  are 
considered  essential  in  a  Joint  Program 
Charter. 

•  Designation  of  the  Joint  Program. 
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•  Statement  of  the  Program  Objective. 
It  is  extremely  important  that  this  sec¬ 
tion  of  the  charter  be  well  written  and 
not  open  to  interpretation.  It  is  where 
the  bounds  are  established. 


•  Definition  of  the  PM’s  Authority, 
Responsibility,  and  Accountability.  The 
accountability  must  be  delineated 
specifically,  since  some  participating 
services  may  want  a  certain  amount  of 
accountability  by  the  PM  to  them,  What 
must  be  avoided  is  having  a  joint  PM 
answering  to  too  many  people  and  orga¬ 
nizations. 


«  Specifications  of  Program  Funding 
and  Resources.  The  Joint  Requirements 
Oversight  Council  (JROC)  issued  a  joint 
Service  position  on  the  preferred  fund¬ 
ing  arrangement  for  joint  programs. 
The  concept  is  presented  in  section  3.0 
of  this  chapter. 

«  Definition  of  the  Services’  Joint  or 
Unilateral  Responsibilities  for  Program 
Execution,  including  service  unique  re¬ 
quirements. 

•  Description  of  the  Relationship  of 
the  Joint  Program  with  Other  Programs, 
Supporting  Organizations,  and  Supported 
Organizations. 

•  Identification  of  the  Chain  of 
Command  for  the  Reporting  and  Reso¬ 
lution  Program  Issues.  Every  attempt 
should  be  made  to  keep  the  issue  reso¬ 
lution  level  as  low  as  possible. 


•  Reporting  Requirements  (Type, 
Format,  and  Frequency).  The  PM 
should  keep  ihe  participating  services 
and  the  user,  especially  the  joint  users, 
informed  of  the  program  status.  Provi¬ 
sions  for  this  type  of  reporting  should 
be  included  in  the  charter. 


•  Program  Office  Organization  and 
Initial  Staffing,  including  in  the  case  of 
the  Navy,  the  PM’s  responsibilities  on 


major  acquisition  programs  to  the  desig¬ 
nated  Program  Executive  Officers 
(PEOs)/Acquisition  Executive. 


•  Requirement  to  Establish  Joint  Op¬ 
erating  Procedures. 

The  following  items  are  "officially"  op¬ 
tional  elements  but  in  reality  should  be 
considered  as  essential: 


•  Assignment  of  the  Deputy  PMs 
from  the  Participating  Services,  Defini¬ 
tion  of  Their  Responsibility  and  Au¬ 
thority  and  Designation  of  their  Rating 
Officials. 

•  Methods  of  Resolving  Conflicting 
Requirements  or  Objectives  of  the  ser¬ 
vices  Involved. 


•  Creation  of  Joint  Committees  for 
Coordination  or  Approval  of  Key  As¬ 
pects  of  the  Program  (/'.t?..  Require¬ 
ments,  Funding,  Source  Selection,  Test 
and  Evaluation  Plans,  and  Configura¬ 
tion). 

•  Performance  Evaluation  of  Person¬ 
nel. 


Review  and  Update.  As  a  joint  program 
progresses  through  the  acquisition  pro¬ 
cess,  management  needs  and  relation¬ 
ships  of  the  participating  services 
probably  will  change.  Therefore,  the 
Joint  Program  Manager  should  review 
the  charter  periodically,  at  least  annu¬ 
ally,  to  ensure  that  its  descriptions  of 
program  mission,  responsibilities  and 
authority  of  the  program  manager,  and 
interservice  relationships  are  still  accu¬ 
rate.  The  charter  should  be  revised  as 
appropriate. 

7.0  SUMMARY 


t  Joint  programs  should  be  established 
and  accomplished  in  accordance  with 
DoDD  5000.1  of  12  March  2986  and 
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DoDI  5000.2  of  12  March  1986.  (Note: 
Currently  being  revised.) 

•  Rationale  for  establishing  joint  pro¬ 
grams  is  primarily  based  on  either  op¬ 
erational  or  economic  considerations,  or 
both. 

•  The  Joint  Requirements  Oversight 
Council  (JROC)  was  created  to  promote 
and  facilitate  the  establishment  and  use 
of  joint  programs.  In  addition,  the 
JROC  has  published  joint  service  posi¬ 
tions  on  the  preferred  funding  arrange¬ 
ment  for  joint  programs,  and  the  policy 
and  procedures  for  joint  potential  re¬ 
view  and  designation  of  programs  and 
requirements. 

•  The  Services  involved  in  a  joint  ac¬ 
quisition  should  follow  the  established 
requirements  process  and  procedures  for 
the  harmonization  of  requirements  as 
specified  in  the  Service’s  directives. 

•  Initiation  of  joint  programs  nor¬ 
mally  occur  during  the  review  of  the 
JMSNS,  budget  reviews,  or  JOR  re¬ 
views. 

•  MOAs  between  the  participating 
services  should  delineate  the  specific 
areas  of  agreement,  subsequent  to  any 
necessary  negotiations  regarding  respec¬ 
tive  service  responsibilities. 

•  Joint  Program  Charters  should  be  as 
specific  as  possible  regarding  the  items 
cited  in  section  6.0  above. 

•  Joint  Program  Charters  should  be 
reviewed  periodically,  and  at  least  an¬ 
nually, 
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CHAPTER  3 

JOINT  REQUIREMENTS 


1,0  SYNOPSIS 

Significant  aspects  and  considerations 
regarding  the  development  of  joint  re¬ 
quirements  are  discussed  in  this  chapter. 
Joint  requirements  rationale  is  presented 
in  section  2.0.  Section  3.0  provides 
guidance  for  the  establishment  of  joint 
requirements.  An  approach  proposed  by 
a  recent  Defense  Science  Board  study,  to 
improved  requirements  management,  is 
discussed  in  section  4.0.  The  prepara¬ 
tion  and  use  of  requirements  documents, 
particularly  the  Justification  for  Major 
Systems  New  Starts  (JMSNS)  is  pre¬ 
sented  in  section  5.0.  Finally,  a  sum¬ 
mary  of  the  chapter  is  provided  in  sec¬ 
tion  6.0. 

2.0  JOINT  REQUIREMENTS  RA¬ 
TIONALE 

The  most  ciitical  aspect  in  commencing 
a  joint  service  acquisition  program  is  the 
delineation  of  the  needs  of  each  partici¬ 
pating  service  and  the  resolution  and 
harmonization  of  those  needs  into  a 
specific  requirements  statement.  The 
General  Accounting  Office  (GAO)  has 
stated  that  getting  agreement  on  joint 
requirements  documents  is  the  number 
one  problem  in  joint  acquisition  pro¬ 
grams.-1-/  Accordingly,  the  statement  of 
operational  requirements  becomes  virtu¬ 
ally  essential  to  the  future  success  of 
any  joint  program.  The  premise  of  a 
joint  program  is  that  there  is  sufficient 
commonality  in  the  services’  require¬ 
ments  that  a  joint  effort  will  be  benefi¬ 
cial.  In  addition,  the  developed  joint 
requirements  must  satisfy  the  operational 
needs  of  all  participating  services  with¬ 
out  unduly  compromising  individual  ser¬ 
vice  needs,  imposing  restrictive  technical 
approaches  on  the  program,  or  develop¬ 
ing  a  system  that  becomes  cost  pro¬ 
hibitive. 


Likewise,  the  requirements  for  tactical 
Command,  Control,  Communications  and 
Intelligence  (C3I)  systems  should  include 
considerations  for  the  compatability  and 
interoperability  of  the  system  with  other 
U.S.  tactical  C3I  systems  and  equipment 
in  accordance  with  DoD  Directive 
4630.5  of  9  October  1985.^ 

3.0  ESTABLISHING  JOINT  RE¬ 
QUIREMENTS 

Normally,  the  sequence  of  events  in  a 
multiservice  acquisition  is  for  the  Joint 
Justification  for  Major  Systems  New 
Starts  (JMSNS)  to  be  prepared  in  accor¬ 
dance  wth  DoD  Directive  5000.)  of  12 
March  1986-/  and  DoD  Instruction 
5000.2  of  12  March  1986-/  or  other  re¬ 
quirements  documents,  in  the  case  of 
non-major  systems,  and  to  be  approved 
prior  to  initiation  of  the  program  and 
appointment  of  the  program  manager. 
In  practice,  events  may  not  occur  in  that 
order  since  many  requirements  docu¬ 
ments  are  being  written  to  support  ex¬ 
isting  programs.  Furthermore,  because 
many  joint  programs  are  created  by 
merging  two  or  more  single-service  pro¬ 
grams,  or  by  existing  Joint  Program  Of¬ 
fices,  the  joint  program  manager  (PM), 
may  need  to  prepare,  coordinate,  or  re¬ 
vise  the  joint  JMSNS  or  Joint  Opera¬ 
tional  Requirements  (JOR)  documents. 
In  any  case,  the  PM  should  ensure  that 
the  statement  of  requirements  meets  the 
needs  of  the  joint  program. 

Several  important  characteristics  of  joint 
requirements  documents,  particularly, 
preliminary  documents,  should  be  con¬ 
sidered.  They  are  negotiated  statements. 
The  tendency  is  for  each  service  to 
overstate  or  overspecify  requirements  to 
ensure  that  its  needs  are  met.  The 
working  of  the  requirements  may  bp  a 
compromise  to  which  each  service  may 
agree,  but  interpret  differently.  Some 


key  aspects  of  the  requirements  may  be 
omitted,  either  through  oversight  or 
because  agreement  was  not  possible. 

At  ihe  outset  of  a  joint  program,  the 
joint  program  manager  should  conduct  a 
detailed  technical  requirements  review 
that  examines  mission  needs,  operational 
concepts  and  environments,  and  perfor¬ 
mance  parameters.  The  PM  should  en¬ 
sure  that  requirements  are  understood, 
that  conflicts  are  resolved,  and  that 
there  is  sufficient  latitude  to  make  the 
trade-offs  essential  to  any  program’s 
success. 

Once  the  requirements  of  each  service 
are  well  understood,  the  joint  program 
manager  should  define  the  set  of  essen¬ 
tial  requirements  which  is  most  de¬ 
manding  in  terms  of  cost,  schedule,  sup¬ 
port,  and  performance  criteria.  This 
will  require  determining  which  require¬ 
ments  are  subsumed  by  others.  It  will 
also  require  determining  the  extent  to 
which  commonality  of  hardware  and 
software,  frequently  an  explicit  or  im¬ 
plied  goal  of  a  joint  program,  is  a  valid 
requirement  and  is  achievable.  Some 
joint  programs  will  be  considered  suc¬ 
cessful  only  if  they  develop  identical  or 
nearly  identical  systems  for  use  in  all 
services.  The  value  of  other  join*’  pro¬ 
grams,  however,  may  be  only  in  sharing 
the  costs  of  concept  formulation  and 
validation  or  in  coordinating  the  engi¬ 
neering  development  of  systems  peculiar 
to  each  service  and  ensuring  their  inter¬ 
operability  trying  to  develop  identical 
or  nearly  identical  systems  for  all  the 
services  may  frustrate  the  program  and 
lead  to  its  failure. 

The  preparation  for  each  milestone  re¬ 
view  (see  Chapter  5,  Program  Review) 
should  include  a  re-examination  of  the 
same  items  reviewed  at  the  initiation  of 
the  joint  program.  This  re-examination 
should  determine  not  only  that  the  par¬ 
ticipating  services’  perception  of  the  re¬ 
quirements  have  not  changed,  but  also 


that  the  threat  or  other  basis  for  estab¬ 
lishing  the  system’s  need  remains  con¬ 
sistent  with  the  initiating  need.  A  re¬ 
vised  threat  assessment  will  bring  about 
a  redirection  of  other  elements  of  the 
JMSNS.  Although  program  require¬ 
ments  stability  is  a  prime  objective,  the 
PM  should  take  the  opportunity  af¬ 
forded  by  the  review  process  to  ensure 
that  the  PM’s  program  meets  the  current 
and  projected  threat  and  that  joint  test 
and  evaluation  demonstrate  the  fulfill¬ 
ment  of  current  and  projected  mission 
requirements. 

4.0  JOINT  REQUIREMENTS  AND 
MANAGEMENT 

The  study  conducted  by  the  Defense 
Science  Board  (DSB)  on  Joint  Service 
Acquisition  Programs  is  recommended 
reading  for  all  joint  acquisition  program 
managers.-/  One  of  the  most  significant 
results  of  the  study  was  the  conclusion 
that  the  issue  of  requirements  is  really 
so  interwoven  with  the  technical  and 
managerial  issues,  that  a  new  process 
was  identified  and  named,  "Joint  Re¬ 
quirements  and  Management"  (JRM). 

The  DSB  identified  several  major  pro¬ 
grams  that  suffered  as  a  result  of  fail¬ 
ures  in  the  JRM  process.  Two  of  these 
were  the  JSTARS  and  the  F-lll. 
Conversely,  the  Defense  Satellite  Com¬ 
munications  System  (DSCS)  was  identi¬ 
fied  as  a  program  given  reasonable 
chance  of  success  partly  because  of  the 
JRM  being  conducted  at  the  start  of  the 
program, 

The  objective  of  the  JRM  process  is  to 
structure  a  program  that  will: 

•  Increase  military  effectiveness, 

«  Achieve  efficiencies  and  economies, 

•  Exploit  technology,  and 
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•  Be  credible  to  the  Congress  and 
public. 

The  process  appears  to  be  highly  itera¬ 
tive  and  composed  of  a  wide  range  of 
interaction.  The  DSB  Study  Group 
concluded  that  there  were  several  major 
issues  that  should  be  resolved  before  a 
joint  program  is  begun.  These  issues 
are: 

•  Operational  concepts, 

•  Performance  specifications  (includ¬ 
ing  interoperability  and  supportability), 

•  Technical  approaches  and  options, 

«  Acquisition  strategy, 

•  Cost  and  schedule, 

•  Relative  worth  vis-a-vis  current 
and  alternative  systems,  and 

•  Management  structure. 

The  manager,  or  prospective  manager  of 
a  joint  program  must  be  prepared  to 
deal  with  differing  organizational  view¬ 
points  between  and  even  within  the  five 
groups  listed  below: 

•  OSD, 

•  JCS, 

•  Unified  Commanders, 

•  Services,  and 

•  Other  government  agencies  and  in¬ 
dustry. 

5.0  REQUIREMENTS  DOCUMENTS 
PREPARATION  AND  USE 

The  basic  requirement  document  for  a 
major  acquisition  program  is  the  Justi¬ 
fication  for  Major  System  New  Starts 
(JMSNS).  Procedures  for  preparing  the 


JMSNS  are  provided  in  DoD  Directive 
5000.2- ^  A  JMSNS  identifies  a  specific 
deficiency  in  a  mission  area,  the  priority 
assigned  to  correcting  the  deficiency, 
and  the  magnitude  of  resources  needed 
to  correct  the  deficiency.  A  brief  out¬ 
line  of  a  JMSNS  is  shown  in  Table  3-1, 
and  a  comprehensive  listing  is  provided 
in  the  DSMC,  "Program  Manager’s 
Notebook."-/  A  joint  JMSNS  documents 
major  deficiencies  in  two  or  more  ser¬ 
vices.  Approval  of  a  JMSNS  is  a  pre¬ 
requisite  for  initiation  of  a  major  system 
acquisition  program. 

Office  of  the  Secretary  of  Defense 
(OSD)  and  Office  of  the  Joint  Chiefs  of 
Staff  (OJCS)  may  additionally  prepare 
JMSNS  in  response  to  mission  area  de¬ 
ficiencies.  When  an  OSD  or  OJCS 
1MSNS  is  submitted,  a  lead  DoD  com¬ 
ponent  should  be  recommended  to  the 
Secretary  of  Defense. 

A  JMSNS  is  required  for  each  major  ac¬ 
quisition,  including  system  modifi¬ 
cations  and  additional  procurement  of 
existing  systems,  which  the  DoD  compo¬ 
nent  anticipates  will  cost  in  excess  of 
$200  million  (FY  1980  dollars)  in  re¬ 
search,  development,  test,  and  evaluation 
(RDT&E)  funds  or  $1  billion  (FY  1980 
dollars)  in  procurement  funds.  A  JM¬ 
SNS  is  not  required  for  programs,  re¬ 
gardless  of  size,  directed  toward  devel¬ 
oping  and  maintaining  a  viable  technol¬ 
ogy  base. 

The  deficiency  or  opportunity  identified 
in  a  JMSNS  should  be  defined  as  nar¬ 
rowly  as  possible  to  al'ow  a  reasonable 
probability  of  correcting  the  deficiency 
by  acquiring  a  single  system.  Defining 
a  broad  architecture  of  systems  to 
counter  projected  threats  in  a  mission 
area  is  part  of  the  ongoing  analysis  of 
mission  areas  rather  than  a  part  of  a 
specific  acquisition  program.  Though 
the  scope  of  the  deficency  identified  in 
a  JMSNS  shall  be  narrowly  defined,  so¬ 
lutions  to  the  problem  shall  not  be 
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A.  DEFENSE  GUIDANCE  ELEMENTS 

1 .  Defense  Guidance  Element  identification 

B.  MISSION  AND  THREAT 

1 .  Mission  area  and  system  application 

2.  DIA-validated  threat  and  current  shortfall 

3.  Timing  of  the  need 

4.  Priority  of  the  system  relative  to  others  in  the  Mission  Area 

C.  ALTERNATIVE  CONCEPTS 

1 .  Known  alternatives  to  be  considered  during  Concept  Exploration 

2.  If  an  alternative  has  been  selected,  describe  why  others  were  rejected 

3.  Remaining  tradeoffs  to  be  conducted  for  selected  system 

D.  TECHNOLOGY  INVOLVED 

1 .  Maturity  of  technology  for  the  selected  system  design  and  production 

2.  Remaining  risk  areas 

E.  FUNDING  IMPLICATIONS 

1.  Affordability 

2.  Component  funding 

3.  Gross  cost  estimates  for  the  selected  concept 

a.  Total  RDT&E 

b.  Total  Procurement 

c.  Life-Cycle  Cost 

F.  CONSTF  VINTS 

1.  Survivability 

2.  Logistics 

3.  Manpower 

4.  Computer  resources 

5.  Standardization  or  interoperability  within  NATO  or  other  DoD  components 

6.  Critical  materials  and  industrial  base  applications 

G.  ACQUISITION  STRATEGY 

1 .  Program  structure 

2.  Competition 

3.  Contracting 


specified.  Alternative  concepts  and  as¬ 
sociated  risks  shall  be  evaluated  in  the 
Concept  Exploration  phase. 

Since  the  JMSNS  is  used  for  joint  pro¬ 
grams  and  other  major  acquisitions,  op¬ 
erational  requirements  for  less-than- 
major  acquisitions  will  probably  con¬ 
tinue  to  be  stated  in  service-peculiar  re¬ 
quirements  documents  which  tend  to  be 
more  detailed  and  more  weapon-system- 
oriented  (vice  mission-oriented)  than  a 
JMSNS.  This  same  practice  is  likely  to 
hold  true  for  joint  acquisitions:  major 
acquisitions  will  be  supported  by  a  joint 
JMSNS;  less-than-major  acquisitions  will 
be  supported  by  a  Joint  Operational  Re¬ 
quirement  (JOR),  or  similar  document, 
which  is  more  detailed  and  more 
weapon-system-oriented  than  a  JMSNS. 

In  the  Army,  the  Deputy  Chief  of  Staff 
for  Operations  and  Plans  (DCOPS)  de¬ 
velops  the  force  requirements  and  pro¬ 
vides  guidance  for  the  preparation  of 
the  JMSNS,  and  Required  Operational 
Capabilities  (ROC).  The  Commanding 
General,  Training  and  Doctrine  Com¬ 
mand  (TRADOC)  subsequently  prepares 
the  documents.-^ 

For  major  programs,  the  Mission  Need 
approval  is  accomplished  by  submitting 
the  JMSNS  along  with  the  Program  Ob¬ 
jectives  Memorandum  (POM),  and 
SECDEF  approves  the  new  start  via  the 
Program  Decision  Memorandum  (PDM). 
For  non-major  programs,  the  Mission 
Need  is  approved  by  the  LOA  for  the 
Designated  Acquisition  Programs  (DAP) 
and  signed  jointly  by  the  materiel  de¬ 
veloper  and  combat  developer.  The 
DAP  is  then  forwarded  to  Headquarters, 
Department  of  the  Army,  HQDA 
(DAMO-RQ)  for  approval.  LOAs  for 
other  programs  are  forwarded  for  in¬ 
formation.  The  Army  Acquisition  Ex¬ 
ecutive  (AAE)  approves  the  DAP  new 
starts  via  the  System  Acquisition  Deci¬ 
sion  Memorandum  (SADM).  Other  pro¬ 
grams  are  approved  by  the  LOA.  Army 


Regulation  71-9  defines  levels  of  ap¬ 
proval  for  the  LOA.-^ 

System  Acquisition  in  the  Navy  is  based 
upon  requirements  documented  in  the 
Operational  Requirement  (OR)  and  the 
Required  Operational  Capability  (ROC) 
for  the  Marine  Corps  in  accordance  with 
OPNAV  Instruction  5000.42C— /  If  the 
program  involved  is  considered  to  be  an 
Acquisition  Category  I  (ACAT  I)  Major 
program,  the  appropriate  mission  spon¬ 
sor  (Deputy  Chiefs  of  Naval  Operations 
(DCNOs))  prepares  the  JMSNS. 

For  all  Department  of  the  Navy  pro¬ 
grams,  the  OR  or  ROC  is  approved  by 
the  CNO  or  CMC.  For  major  programs 
a  JMSNS  is  then  submitted  with  the 
next  Navy  POM  submittal.  Major  pro¬ 
grams  are  approved  by  the  Secretary  of 
Defense  via  the  Program  Decision  Mem¬ 
orandum  (PDM).  A  Tentative  Opera¬ 
tional  Requirement  (TOR)  document  is 
developed  by  OPNAV  which  describes  a 
need  for  a  new  system  in  general  terms. 
The  TOR  is  distributed  to  the  appropri¬ 
ate  SYSCOM.  A  Development  Option 
Paper  (DOP)  that  is  based  on  the  explo¬ 
ration  of  options,  is  created  by  the 
SYSCOM,  which  describes  a  range  of 
possible  systems  covering  a  spectrum  of 
capabilities  that  are  considered  respon¬ 
sive  to  the  TOR.  The  DOP  is  submitted 
to  OPNAV  and  SECNAV  for  considera¬ 
tion.  Subsequently,  an  Operational  Re¬ 
quirement  (OR)  document  is  developed 
that  describes  the  major  characteristics 
of  the  alternative  selected  by  the  OP¬ 
NAV  sponsor,  as  a  result  of  the  DOP 
review,  which  best  matches  the  desired 
capabilities  within  affordability  limita¬ 
tions. 

In  the  Air  Force,  requirements  originate 
in  the  operating  commands,  such  as  the 
Tactical  Air  Command  (TAC),  where 
they  are  documented  as  Statements  of 
Need  (SON)  in  accordance  with  Air 
Force  Regulation  (AFR)  57- lj u/  AFR 
57-1  is  supported  by  the  Air  Force  800 
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series  regulations  for  acquisition  and 
implementation  procedures  provided  by 
AFSC  pamphlet  800-3.  A  SON  that 
may  lead  to  major  system  acquisition 
program  is  transformed  into  a  JMSNS  by 
the  Deputy  Chief  of  Staff  (Operations, 
Flans,  and  Readiness)  (AF/XOX)  and 
the  Deputy  Chief  of  Staff  (Research, 
Development  and  Acquisition)  (AF/ 
RDQ) 

When  a  Joint  or  OSD/OJCS  JMSNS  is 
submitted,  the  SECDEF  decision  is  then 
documented  in  a  Secretary  of  Defense 
Decision  Memorandum  (SDDM). 

6.0  SUMMARY 

•  Obtaining  agreement  on  joint  re¬ 
quirements  documents  has  been  identi¬ 
fied  by  GAO  as  a  major  problem  in 
joint  acquisition  programs. 

•  Joint  requirements  must  satisfy  the 
operational  needs  of  all  participating 
services  without  unduly  compromising 
individual  service  needs,  imposing  re¬ 
strictive  technical  approaches  on  the 
program  or  developing  a  system  that 
becomes  cost  prohibitive. 

•  Consideration  must  be  given  to  tac¬ 
tical  C3I  systems  compatability  and  in¬ 
teroperability  with  other  applicable  sys¬ 
tems. 

t  Development  of  the  requirements 
documents  require  the  special  attention 
of  the  joint  program  manager  in  harmo¬ 
nizing  the  needs  of  the  participating 
services. 

•  To  improve  a  joint  program's 
chances  for  success,  consider  the  ap¬ 
proach  of  Joint  Requirements  and 
Management  (JRM)  proposed  by  the 
Defense  Science  Board  (DSB). 

•  The  basic  requirements  document 
for  a  major  acquisition  joint  or  single 


service  program  is  the  Justification  for 
Major  Systems  New  Starts  (JMSNS). 

•  Less-than-major  joint  acquisition 
program  requirements  are  documented 
by  a  Joint  Operational  Requirement 
(JOR),  or  similar  document. 

«  Each  of  the  services  have  different 
procedures  for  the  development  of  re¬ 
quirements  documents. 
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CHAPTER  4 

ACQUISITION  STRATEGY 


1.0  SYNOPSIS 

This  chapter  dealing  with  acquisition 
strategy  provides  the  reader  with  the 
general  aspects  of  acquisition  strategy  as 
it  relates  to  the  acquisition  process,  the 
current  references  and  implementing 
directive;  and  the  unique  aspects  of  joint 
programs.  The  manner  in  which  these 
aspects  relate  to  the  development, 
implementation  and  modification  of  an 
acquisition  strategy  in  a  major  acquisi¬ 
tion  will  also  be  presented.  Section  2,0 
addresses  the  development  of  Acquisi¬ 
tion  Strategy,  Section  3.0  discusses  ten 
major  strategy  issues,  and  Section  4.0 
summarizes  this  chapter  of  the  guide. 

Because  no  two  programs  are  exactly 
alike,  each  requires  a  tailored  acquisition 
strategy.  A  joint  program  offers  an¬ 
other  dimension  of  the  acquisition 
strategy  for  management  consideration. 
A  joint  program  strategy  can  be  struc¬ 
tured  from  the  beginning  if  the  proper 
multiservice  requirements  can  be  nego¬ 
tiated.  DoD  Directive  5000.1  requires 
that  "acquisition  of  equipment  satisfying 
DoD  component  needs  should  also  in¬ 
clude  consideration  of  intetservice  and 
intraservice  standardization  and  inter¬ 
operability  requirements."  This  consid¬ 
eration  should  be  made  prior  to  the  is¬ 
suance  of  a  Secretary  of  Defense  Deci¬ 
sion  Memorandum  (SDDM)  specifying  a 
lead  service  and  providing  explicit 
guidance  on  the  responsibilities  of  the 
participating  services. 

Figure  4-1,  from  the  Program  Manager’s 
Notebook  illustrates  the  differences 
between  Acquisition  Strategy,  which 
provides  the  conceptual  framework  the 
PM  will  follow  and  the  Acquisition  Plan 
which  is  prepared  by  the  contracting 
office  and  is  more  activity  and  issue 
oriented.  Table  4-1,  also  from  the  Pro¬ 
gram  Manager’s  Notebook,-^  illustrates  a 


comprehensive  list  of  Acquisition  Strat¬ 
egy  elements. 

2.0  DEVELOPING  THE  ACQUISI¬ 
TION  STRATEGY 

Acquisition  strategy  defines  the  interre¬ 
lationship  between  management,  tech¬ 
nical,  business,  resource,  force  structure, 
support,  testing,  and  the  aspects  of  the 
program. 

The  primary  value  of  strategic  planning 
is  the  interactive  process  through  which 
the  final  product  is  developed.  The  ac¬ 
quisition  strategy  evolves  through  repe¬ 
tition  as  a  dynamic  management  tool 
which  must  be  kept  current  throughout 
the  life  of  the  program.  It  must  also 
address  typical  management  issues  from 
development  to  production  that  assess 
the  impact  of  different  levels  of  fund¬ 
ing  problems  in  testing,  changes  in  re¬ 
quirements,  control  of  engineering 
changes,  length  of  product  maturation, 
and  effects  of  lead  time.  The  acquisi¬ 
tion  strategy  should  delineate  realistic 
responses  to  program  variances  consid¬ 
ered  disruptive  to  key  program  efforts. 

The  acquisition  strategy  should  reflect 
the  full  scope  of  the  program  with  sen¬ 
sitivity  to  the  acquisition  process,  imagi¬ 
nation,  and  practical  judgment  of  pro¬ 
gram  managers.  Whenever  large  pro¬ 
curement  quantities  and  relatively  high 
unit  costs  are  part  of  the  acquisition,  the 
program  manager  has  a  full  range  of  ac¬ 
quisition  strategies  available  to  structure 
the  program.  The  PM  should  also  make 
maximum  use  of  competition  to  obtain 
the  trade-offs  between  cost,  perfor¬ 
mance,  schedule,  and  supportability  to 
the  best  advantage  of  his  program  where 
there  is  a  net  benefit  to  the  government 

The  Army,  Navy,  and  Air  Force  each 
address  acquisition  planning  and  strategy 
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Figure  4-1  Comparison  of  Acquisition  Strategy  and  Acquisition  Plan 


TABLE  4-1  ACQUISITION  STRATEGY  ELEMENTS 


ELEMENTS  OF  A  108 
ACQUISITION  STRATEGY 

ELEMENTS  OF  FAR 

ACQUISITION  PLANNING 
(PART  7) 

ELEMENTS  OF  AIR  FORCE 

PROGRAM  MANAGEMENT  PLAN 
(AFR  BOO-2.31 

•  Contracting  Process 

•  Scheduling  ol  Essential  Element* 

•  Demonstration  Test  and  Evaluation 

Cftlirii 

•  Content  of  Solicitation*  for  Prop©**!* 

e  Decision*  on  Whom  to  Solicit 

•  Method*  for  Obtaining  and  Sustaining 
Competitor! 

•  Guideline*  for  Evaluation  and 

Acceptance  or  Rejection  of  Proposals 

•  Goals  for  Desigrvto-Cost 

•  Methods  for  Projecting  life- Cycle 

Coats 

•  Use  of  Data  Rights 

•  Uaa  of  Warranties 

•  Methods  for  Analysing  and  Evaluating 
Contractor  and  Government  Risks 

«  Need  for  Developing  Contractor 
Incentives 

•  Selection  for  the  Type  of  Contrect 

Best  Suited  for  Etch  Stage  in  the 
Acquisition  Process 

•  Administration  of  Contracts 

ACQUISITION  BACKGROUND  AND 
OBJECTIVES 

•  Statement  of  Need 

•  Applicable  Conditions 

—  Requirements  for  competability  with 
emitting  or  fulure  systems  or 
programs 

—  Any  known  coat,  schedule,  capability, 
or  performance  constraints 

•  Cost 

—  Life-cycle  cost 

—  Design- to- cost 

—  Application  of  should-cost 

•  Capability  or  Performance 

a  Delivery  or  Performance-Priced 
Requirement* 

•  Trede-Offa 

•  Risks 

PLAN  OF  ACTION 

•  Sources 

•  Competition 

•  Source-Selection  Procedures 

•  Contracting  Considerations 

•  Authority  for  Contracting  by 

Negotiations 

•  Budgeting  and  Funding 

PRODUCT  DESCRIPTIONS 

•  Priorities.  Allocations,  and  Allotments 

•  Contractor  Versus  Government 

Performance 

•  Management  information 

Requirements 

•  Make  or  Buy 

•  Test  and  Evaluation 

•  Logistics  Considerations 

—  Assumptions  determining  contractor 
or  agency  support. 

—  Reliability,  meint  a  inability,  and 
quality  assurance  requirements, 
including  any  planned  use  of 
warranties 

—  Requirements  for  contractor  data 
(Including  repurchase  deu)  and  data 
rights,  theli  estimated  coat,  and 
the  use  to  be  made  of  the  date. 

•  Government* Furnished  Property 

•  Government-Furnished  Information 

•  Environmental  Considerations 

•  Security  Considerations 

•  Other  Considerations 

•  Milestones  for  the  Acquisition  Cycle 

«  Identified  lion  of  Participants  in 

Acquisition  Plan  Preparation 

•  Program  Summary  end 

Authorisation 

•  Intailigenca 

•  Program  Management 

•  System  Engineering 

•  Test  end  Evaluation 

•  Communications/ Electronics 

•  Operations 

•  Civil  Engineering 

•  Manpower  and  Organisation 

•  Personnel  Training 

•  Security 

•  Directives  Application 
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TABLE  4-1  ACQUISITION  STRATEGY  ELEMENTS 

(Continued) 


ELEMENTS  OF  ARMY 
ACQUISITION  STRATEGY 
(An  70- 1) 


ELEMENTS  OF  NAVY 
ACQUISITION  STRATEGY 
SECNAVINST  4200  33 


ELEMENTS  OF  RECENT 
EXAMPLE  ACQUISITION  PLAN 


•  Program  Structure 

•  Contract^  Strategy 

•  Tailoring  the  Acquisition 

Procaw 

4  Supported  ity 
4  Manufacturing  end  Production 
4  Taal  and  Evaluation 
4  Coat  Growth  and  Orivart 

•  Technical  Rieka 

4  Safety  and  Health 
a  SoJdier-Mechine  interface 

a  Rationalisation.  Standardisation 
and  Intai operability  (RSI) 

4  Survivability  and  Endurance 
a  Short-Term  lasuea 


4  Section  I:  Needs,  Constraints. 

thresholds,  and  Program 

Structure 

—  Statement  ot  need 

—  Proqism  constraints  and/or 
thresholds 

—  Resource*  and  funding 

—  Program  structure 
4  Section  II;  Risk  Analysis 

4  Section  III:  Strategy  to  Achieve 

Objectives  and  Implementation 

—  Objectives  and  goala  for  the 
acquisition  effort 

—  Consideration  and  rationale 
for  program  schedule 

—  Planning  and  control  of  critical 
program  activities 

—  Acquisition  alternatives 

—  The  plan  for  sal  acting  among 
alternatives  and  the  timing 
of  key  selection  decisions 

—  The  interdependence  of  the 
acquisition  effort  with  other 
programs 

—  Risk  management  plan 

—  The  approach  for  design, 
hardware  date  development, 
and  Preplanned  Product 
improvement  (P^l) 

—  Plans  for  achieving  railsbility 
in  design  snd  manufacturing 

—  Standardization 
considerations 

—  Ds sign- to- cost  and 

affordability  cor.  side  rations 

—  Integrated  logistics  support 
approach 

—  Us#  of  organisational  assets 

—  Mobilisation  capability 

—  A  financial  strategy 

—  Plena  for  and  funding  required 
to  acquire  adequate 
subsystems  and  system  test 
herdware 

—  The  business  management 
approach 

-  An  audit  trail  of  key  acquisition 
decisions 


4  Program  Description 
4  Program  Funding 
4  Delivery  Requirements 

4  Applicability  of  Decision 
Coordinating  Paper  (DCP)  and 
Defense  Acquisition  Board  (DAB) 

4  Background  and  Acquisition 
History 

4  Program  Risks 

4  Integrated  Logit  tics  Support 
(IIS)  Planning 

4  Application  of  Desigrvto-Cost 
(D1C) 

4  Application  of  Life-Cycle  Cost 
(ICC) 

•  Reliability.  Maintainability,  and 
Quality  Assurance  (H.M.CLA) 
Objectives 

4  Test  and  Evaluation  Approach 

e  Management  Information  and 
Program  Controls 

•  Approval  for  Full  Production 
(AFP) 

•  Gov  •  *nt-Furniahed 

Pr<  litias/ Component 


jas  Planning 


4  Contract i >u 
4  Long-Range  Pir.n 


V\  O  N  '  *S.,‘ 


development  in  slightly  different  ways. 
In  the  Army,  Acquisition  Strategy  and 
Acquisition  Plan  are  two  separate  docu¬ 
ments.  See  AR  70-1  .  In  the  Navy, 

in  accordance  with  SECNAVINST 
4200. 33, the  Acquisition  Plan,  as  cov¬ 
ered  by  Part  7  of  the  Federal  Acquisi¬ 
tion  Regulation  (FAR),  satisfies  the  Ac¬ 
quisition  Strategy  requirements.  Also, 
SECNAVINST  4210.667  provides  Navy 
guidance  in  the  area  of  Acquisition  Pol¬ 
icy  and  Srategy.  For  the  Air  Force,  the 
acquisition  strategy  and  acquisition  plan 
are  synonymous  and  are  an  integral  part 
of  the  Program  Management  Plan  (PMP) 
as  prescribed  by  AFR  800-2,  AFSC 
supplement  to  800-2  and  AFCP  800-3. 

The  acquisition  strategy  should  include  a 
listing  of  critical  pacing  technology  ad¬ 
vances  required  to  satisfy  the  program 
thresholds.  The  initial  acquisitions 
strategy  after  Program  Initiation  may 
only  contain  a  few  pacing  technology 
advances  required  since  alternatives  have 
not  yet  been  explored.  As  the  concept 
formulation  phase  proceeds,  however, 
advances  should  become  defined  in  de¬ 
tail  as  the  preferred  alternatives  are 
considered.  The  critical  pacing  technol¬ 
ogy  advances  required  for  each  alterna¬ 
tive  drives  the  technology  risk  assess¬ 
ment  in  the  analysis  for  the  alternative 
concepts.  Once  the  preferred  alterna¬ 
tive^)  is  chosen  at  Milestone  I,  the  ad¬ 
vances  required  should  be  well  known 
and  an  evaluation  of  risks  for  develop¬ 
ing  those  technologies  to  the  point  of 
being  able  to  meet  the  performance, 
cost,  schedule,  and  supportability 
thresholds  should  be  understood.  The 
program  manager  must  then  manage 
these  risks  through  the  acquisition 
strategy  by  assigning  and  controlling 
critical  resources  (time,  money,  person¬ 
nel)  to  achieve  the  required  technology 
advances  with  special  attention  to  the 
critical  pacing  technologies. 

When  technical  risk  and  progress  are 
acceptable,  short-term  fixed-price  con¬ 


tracts  are  sometimes  used  to  evaluate 
and  explore  selected  concepts.  This  can 
aid  in  reducing  technical  uncertainties 
for  alternative  approaches.  Unsuccessful 
approaches  are  eliminated  by  continuous 
tests  of  contractor  and  in-house  labora¬ 
tory  efforts. 

3.0  ACQUISITION  ISSUES 

The  previous  section  presented  a  table 
■'f  acquisition  strategy  elements  as  ex- 
.racted  front  FAR,  DAR,  and  OMB 
Circular  A- 109.  These  elements  may  be 
regrouped  as  lower  levels  of  a  structure 
called  Acquisition  Strategy  Issues.  The 
Acquisition  Strategy  Guide  ,  has  iden¬ 
tified  thirteen  major  issues  which  may 
be  used  to  organize  the  multitude  of  ac¬ 
quisition  strategy  elements  to  be  con¬ 
sidered  by  the  Joint  Program  Manager. 
Ten  of  these  thirteen  issues  are  synop- 
sized  below  and  modified  where  neces¬ 
sary  to  address  the  Joint  environment. 

issue  1  -  Competition.  Defense  compe¬ 
tition  can  take  many  forms.  These  may 
be  no  competition,  for  example,  where  a 
sole-source  procurement  is  directed  or  a 
selection  is  made  because  of  the  nature 
of  the  product  and  the  availability  of 
qualified  sources.  Where  there  is  direct 
competition,  it  may  involve  two  or  more 
companies,  and  it  may  occur  during  re¬ 
search,  development,  or  production  of  a 
product.  Two  generic  forms  of  compe¬ 
tition  are  recognized  in  military  acquisi¬ 
tion: 

•  Design  Competition.  Two  or  more 
companies  develop  conceptual  or  design 
approaches,  one  or  more  of  which  will 
be  used  for  the  production  contract. 
The  competition  can  be  extended 
through  the  Demonstration  and  Valida¬ 
tion  phase  and  into  the  Full  Scale  De¬ 
velopment  phase  to  obtain  prototype 
performance  verification  and  to  provide 
a  natural  competition  for  the  production 
contract.  Typically,  in  large  programs 
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design  competition  ceases  at  Full  Scale 
Development, 

•  Production  Competition.  Two  or 
more  companies  bid  to  secure  all  or  part 
of  a  production  contract.  Thus  there 
may  be  a  winner-take-ail  competition  or 
the  production  may  be  split  between  two 
contractors.  The  competitors  may  have 
participated  in  the  program  prior  to  the 
first  production  contract,  or  one  or  more 
may  have  been  brought  in  through  a 
second-sourcing  strategy. 

The  DSMC  Handbook  Establishing 
Competitive  Production  Sources-/  nrn- 
vides  details.  The  approaches  to  estab¬ 
lishing  second  sources  for  production 
have  received  the  greatest  attention,  for 
it  is  in  this  phase  that  the  major  expen¬ 
ditures  are  made  during  acquisition. 
The  following  methods  have  been  iden¬ 
tified: 

•  Form-Fit-Funetion  (F3).  Only 
functional  requirements  and  size, 
weight,  and  interface  parameters  are 
specified,  permitting  one  "black  box"  to 
replace  another.  It  is  applicable  with 
break-out. 

•  Technical  Data  Package.  Data  are 
purchased  to  enable  qualified  contractors 
to  produce  the  equipment. 

•  Directed  Licensing.  This  is  similar 
to  leader-follower  except  that  the  leader 
company  is  compensated  for  technology 
transfer  through  royalty  or  licensing 
fees. 

•  Leader-Follower.  The  system  de¬ 
veloper  or  sole-source  producer  fur¬ 
nishes  assistance  to  a  follower  company 
to  establish  the  latter  as  a  second  source. 
Since  the  leader  company  has  a  natural 
reluctance  to  lose  its  sole-source  posi¬ 
tion,  contractual  commitments  must 
generally  be  made  at  an  appropriate 
time  to  ensure  the  viability  of  this  ap¬ 
proach. 


•  Contractor  Teams.  Teams  of  indi¬ 
vidually  competent  contractors  bid  for 
the  development  contract,  thus  providing 
multiple  qualified  sources  for  the  system 
during  the  production  phase. 

•  Break-Out.  A  critical  subsystem  or 
component  is  selected  for  competitive 
production  in  out-year  buys.  A  subsys¬ 
tem  component  that  is  broken  out  may 
become  GFE. 

Competition  by  several  companies  for 
the  same  system  should  always  be  con¬ 
sidered  in  new  systems  acquisition.  It  is 
not  always  implemented,  for  a  variety  of 
reasons.  However,  there  can  also  be  in¬ 
direct  competition  in  that  the  mission 
need  can  be  met  by  a  substitute  product 
or  item  requiring  no  further  develop¬ 
ment.  Examples  are  the  C-5B  and  C- 
17  transports  to  meet  the  a-rlift  mission, 
and  K.C-135  re-engine  and  K.C-10 
tankers  to  meet  the  air  refueling  mis¬ 
sion.  Some  leverage  is  thus  maintained 
over  contractors  in  that  these  mission 
competitors  do  compete  for  the  same 
funding. 

Issue-2...  -  ConcucreiiCY/Time.  Phasing. 
The  acquisition  cycle  has  been  length¬ 
ening  over  the  past  decades,  and  con¬ 
currency  (overlapping  of  task  schedules) 
is  one  approach  that  is  usually  consid¬ 
ered  to  shorten  the  time  required  to 
achieve  an  earlier  Initial  Operational 
Capability  (IOC).  However,  the 
lengthening  of  the  acquisition  cycle  has 
not  been  due  to  a  lengthening  develop¬ 
ment  phase,  but  rather  to  longer  times 
prior  to  development  and  longer  pro¬ 
duction  spans  after  development.  Con¬ 
currency  ihai  requires  the  overlapping 
of  Full  Scale  Development  (FSD)  activi¬ 
ties  in  design,  test  and  evaluation,  and 
production  and  deployment  can  increase 
the  risks  of  not  achieving  performance, 
schedule,  support  and  cost  objectives. 
This  is  true  particularly  when  testing  an 
initial  production  and  fielding  of  the 
equipment  overlap  considerably  and 


there  is  not  sufficient  time  to  use  test 
results  to  correct  design  deficiencies. 

One  problem  in  determining  the  extent 
to  which  concurrency  can  be  applied 
(how  much  compression  in  the  schedule 
can  be  tolerated)  is  understanding  the 
difficulty  of  the  program  before  starting 
FSD.  Consideration  should  be  given  to 
technology  advances  sought  and  com¬ 
plexity  of  the  system  relative  to  the  de¬ 
sired  IOC  data  and  the  amounts  and 
types  of  testing  required  to  reduce  de¬ 
sign  uncertainty.  Oil  the  one  hand,  IOC 
is  desired  as  early  as  possible.  On  the 
other  hand,  sufficient  time  must  be  al¬ 
lowed  for  the  FSD  actvities  leading  to 
IOC.  It  may  not  be  a  matter  of  more- 
money  and  people  to  shorten  the  time; 
certain  activities  cannot  be  accomplished 
very  much  sooner  no  matter  how  exten¬ 
sive  the  resources  applied. 

The  transition  from  Full  Scale  Develop¬ 
ment  to  Production  and  Deployment  is 
the  most  difficult  period  to  manage,  and 
thus  a  great  burden  is  placed  on  the 
Government  and  industry  management 
teams  to  accomplish  all  required  activi¬ 
ties  within  constrained  schedule  and 
cost.  The  usual  approach  is  to  conduct 
design,  test,  production,  and  deployment 
in  a  sequential  manner,  particularly 
testing  leading  to  production,  so  that  the 
information  available  from  testing  can 
be  fully  utilized  to  "mature"  the  design 
and  finalize  the  production  article.  In 
this  sequential  case  the  total  time  can  be 
much  too  long  compared  with  the  de¬ 
sired  IOC  if  there  is  urgency  in  fielding 
the  system.  Compromises  concerning 
activities  and  their  durations  involved  in 
this  transition  will  largely  depend  upon 
the  unique  circumstances  of  each  indi¬ 
vidual  program,  or  may  be  based  upon 
past  experiences  of  similar  or  analogous 
activities. 

•  Alternative  Forms.  Concurrency  is 
the  overlapping  of  design,  testing,  pro¬ 
duction,  and  deployment  activities.  The 


overlapping  and  elimination  of  phases  in 
the  acquisition  cycle,  as  well  as  ovei lap¬ 
ping  or  eliminating  activities  within  a 
phase,  are  also  possible  choices  based  on 
the  urgency  of  need  or  maturity  of  the 
system.  The  pacing  subsystem(s)  and 
activities  must  be  identified,  and  ade¬ 
quate  time  must  be  allowed  for  design 
and  test.  During  Full  Scale  Develop¬ 
ment,  there  must  be  a  commitment  to 
production  from  the  outset  (e.£.,  a  Na¬ 
tional  need),  because  test,  production, 
and  deployment  decisions  must  be  made 
much  earlier  during  design  and  testing 
activities.  The  effects  of  concurrency 
on  timely  supportability  must  also  be 
considered.  A  realistic  evaluation  of 
available  technology  and  previous  expe¬ 
rience  is  critical.  It  may  be  necessary  to 
simulate  designs  before  testing  in  order 
to  speed  design  decisions.  Early  testing 
is  critical  to  the  verification  of  design 
uncertainties  but  requires  hardware  de¬ 
livery  and  test  set-up,  which  can  require 
considerable  additional  time  and  early 
resources. 

Issue  3  -  Data  Rights.  Section  27  of  the 
FAR  and  DFAR  addresses  the  issues  of 
data  and  data  rights.  Data  rights  are  the 
limitations  placed  on  the  Government  in 
using  technical  data  delivered  as  part  of 
a  contract. 

There  have  been  major  studies  in  the 
areas  of  data  and  data  rights,  with  the 
focus  being  placed  upon  a  central  issue 
of  how  much  data  the  government 
should  acquire  rights  to,  and  for  what 
reason.  Industry  often  takes  the  view 
that  the  total  economic  health  of,  the 
country  is  improved  by  industry  reten¬ 
tion  of  rights,  while  the  government  is 
obligated  to  make  sure  that  work  which 
is  funded  by  the  government  is  available 
for  all  legitimate  purposes,  including 
competition. 

The  revised  DoD  rules  regarding  rights 
in  technical  data  were  published  in  the 
Federal  Register  in  April  1987,  with  an 


effective  date  of  18  May  1987.  A  ver¬ 
sion  of  rights  in  technical  data  to  be 
used  by  all  federal  agencies,  including 
NASA,  but  the  Department  of  De¬ 
fense,  was  issued  in  May  under  Federal 
Acquisition  Circular  (FAC)  84-27.  The 
current  plan  is  for  a  uniform  set  of 
guidance  to  be  developed  and  imple¬ 
mented  by  the  end  of  September  1988. 

There  ate  two  basic  categories  of  data 
rights  in  the  Federal  Acquisition  Regu¬ 
lation  (Part  27):  Limited  Rights  and 
Unlimited  Rights  where  "Limited 
Rights"  allows  the  government  to  repro¬ 
duce  and  use  the  data  within  the  gov¬ 
ernment,  but  without  the  contractor's 
permission,  the  government  may  ngt 
disclose  the  data  outside  the  government 
nor  use  it  for  purposes  of  manufacture. 
Other  specific  uses  may  be  identified  in 
the  FAR  Limited  Rights  Notice  Clause 
and  included  as  a  solicitation  provision 
or  contract  clause. 

"Unlimited  Rights"  means  that  the  gov¬ 
ernment  may  use,  disclose  and  distribute 
the  data  and  have  or  permit  others  to  do 
so  also.  The  determination  of  what 
constitutes  limited  rights  data  and  un¬ 
limited  rights  data  is  complex,  but  pri¬ 
marily  based  on  who  has  paid  for  the 
development.  In  the  civilian  agency 
version  of  the  rights  rules,  if  the  gov¬ 
ernment  contributed  (funded)  any.  part 
of  the  development,  then  the  govern¬ 
ment  should  receive  unlimited  rights. 
Therefore,  the  unlimited  rights  restric¬ 
tion  is  based  on  full  contractor  funding 
of  the  development  which  resulted  in 
the  data.  Herein  lies  the  major  differ¬ 
ence  between  the  civilian  agency  and 
DoD  data  rules. 

With  the  publication  of  the  revised  data 
rights  rules,  there  are  now  three  cate¬ 
gories  of  standard  rights  in  technical 
data  which  are:  Unlimited  Rights, 

Limited  Rights,  and  the  new  category. 
Government  Purpose  License  Rights. 
The  key  difference  between  the  civilian 


and  DoD  versions  is  that  the  contracting 
offices  in  the  DoD  case  are  allowed  to 
determine  whether  unlimited  rights  are 
required  even  though  the  government  is 
entitled  to  unlimited  rights  by  virtue  of 
contributing  to  the  development.  Since 
the  policy  of  DoD  is  to  not  acquire  more 
data  rights  than  required,  the  new  gov¬ 
ernment  purpose  license  rights  may  be 
applied  in  mixed  funding  situations. 
Government  purpose  license  rights  per¬ 
mits  the  government  to  use,  duplicate  or 
disclose  the  data  for  any  government 
purpose  including  competitive  procure¬ 
ment,  but  does  not  grant  others  to  use 
the  data  for  commercial  purposes. 

The  term  associated  with  limited  use  of 
software  data  is  "Restricted  Rights." 
Restricted  rights  permits  the  government 
to  use  the  software  with  the  computer 
for  which  it  was  acquired,  even  if  the 
computer  is  transferred;  to  use  it  with 
backup  computers;  to  make  backup 
copies;  and  to  create  derivative  software 
which  will  have  the  same  restrictions. 

The  DoD  policy  on  data  is  to  acquire 
only  such  technical  data  rights  that  arc 
essential  to  meet  Government  needs. 
The  Program  Manager  must  determine 
whether  the  expense  of  acquiring,  stor¬ 
ing,  and  maintaining  data  is  justified. 

For  any  contract,  the  Government  has  a 
legitimate  need  for  data  to  support  such 
functions  as  operation,  maintenance, 
training,  standardization,  and  logistics 
support.  Of  primary  concern  is  the 
purchase  of  data  to  provide  the  capabil¬ 
ity  to  produce  the  item  by  sources  other 
than  the  original  manufacturer.  This 
was  part  of  the  motivation  for  the 
Government  Purpose  License  Rights. 

When  a  sole-source  production  contract 
is  awarded,  the  Government  is  placed  in 
the  position  of  having  to  depend  on  the 
contractor  for  additional  units,  spares, 
and  modifications.  To  avoid  such  com¬ 
plete  dependence,  strategic  planning  can 


include  such  options  as  competitive  pro¬ 
duction,  leader-follower,  and  licensing. 
Data  rights  are  required  to  exercise  op¬ 
tions  for  avoiding  sole-source  depen¬ 
dence.  If  the  contractor  cannot  or  does 
not  want  to  produce  the  equipment,  the 
purchased  data  can  be  used  to  so'Uit 
other  sources,  or  possibly  the  equipment 
can  be  produced  in  Government  facili¬ 
ties.  When  the  data  being  considered 
are  proprietary,  the  expense  of  acquisi¬ 
tion  will  generally  be  higher,  especially 
if  the  Government  sees  a  need  for  ac¬ 
quiring  unlimited  rights. 

There  are  a  number  of  issues  associated 
with  data  rights.  A  subcontractor  may 
refuse  to  deliver  data  pertaining  to  its 
product  even  though  all  prime  contrac¬ 
tor  data  fall  in  the  category  of  unlimited 
rights.  A  process  called  Predetermina¬ 
tion  of  Rights  in  Technical  Data  is  used 
to  identify  and  establish  agreements  on 
proprietary  data. 

Another  related  issue  is  patent  rights. 
In  its  simplest  form,  it  offers  two  possi¬ 
bilities: 

«  The  contractor  retains  patent  rights, 
and  the  Government  receives  a  non- 
transferable  license  to  use  the  patent. 

•  The  patent  rights  are  retained  by 
the  Government,  and  the  contractor  re¬ 
ceives  a  nonexclusive  license  to  use  the 
patent. 

Two  related  issues  concern  NATO  RSI 
licensing  and  the  Freedom  of  Informa¬ 
tion  Act.  United  States  companies  find 
it  difficult  to  obtain  proprietary  rights 
and  to  acquire  European  patents  on 
equipments  scheduled  for  NATO  RSI 
production.  However,  because  of  the 
data  rights  policies  of  European  coun¬ 
tries,  European  contractors  can  obtain 
patent  and  technical  data  rights  in  both 
Europe  and  the  United  States  much 
more  easily. 


The  Freedom  of  Information  Act  is  a 
potential  source  of  concern  for  contrac¬ 
tors.  The  Government  has  the  sole  au¬ 
thority  to  bar  release  of  proprietary  in¬ 
formation  under  this  Act  (Exception 
Four).  Recent  court  decisions  concern¬ 
ing  the  Act  and  the  lack  of  any  control 
by  the  contractor  could  jeopardize  the 
contractor’s  competitive  position.  Con¬ 
tractors  may  therefore  be  reluctant  to 
provide  complete  data. 

Issue  4  -  Desien-to-Cost.  DoD  Direc¬ 
tive  4245.3  of  April  6,  1983-^  defines 
Design-To-Cost  (DTC)  as: 

"An  acquisition  management  technique  to  achieve 
defense  system  designs  that  meet  stated  cost  re¬ 
quirements.  Cost  is  addressed  on  a  continuing  basis 
as  part  of  a  system's  development  and  production 
process.  The  technique  embodies  early  establish¬ 
ment  of  realistic  but  rigorous  cost  objectives,  goals, 
and  thresholds  and  a  determined  effort  to  achieve 
them." 

The  DTC  goal  initially  established  is  the 
average  unit  flyaway  (or  rollaway, 
sailaway)  cost  associated  with  an  end 
item  of  military  hardware.  As  the  abil¬ 
ity  to  translate  operations  and  support 
cost  elements  into  "design  to"  require¬ 
ments  improves,  DTC  goals  and  thresh¬ 
olds  are  derived  from  the  total  Life- 
Cycle-Cost  (LCC)  considerations. 

The  DTC  process  is  directed  toward 
controlling  cost  in  an  effort  to  modern¬ 
ize  DoD  weapon  systems  in  sufficient 
quantities  to  provide  a  suitable  deter¬ 
rence  and  fighting  capability  at  an  af¬ 
fordable  cost.  Before  the  DTC  process 
was  established,  weapon  system  costs 
had  been  rising  at  a  rate  much  faster 
than  inflation.  The  most  common  rea¬ 
sons  cited  for  cost  growth  (in  addition  to 
quantity  changes)  in  past  programs  were: 

e  Initially,  poor  estimates  of  costs. 

•  Cost  escalation  due  to  inflation. 
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•  Cost  growth  due  to  changes. 

»  Overhead  escalation  due  to  reduced 
business/production,  e.g .,  changes  in 
business. 

DTC  is  one  of  the  many  tools  available 
for  establishing  cost  controls.  An  in¬ 
herent  part  of  the  DTC  process  is  the 
capability  to  evaluate  the  impact  of 
performance  trades  to  meet  DTC  objec¬ 
tives,  goals,  and  thresholds.  To  be  use¬ 
ful,  DTC  efforts  need  to  be  sufficiently 
flexible  to  accommodate  program 
changes  and  provide  an  audit  trail  of  the 
impact  of  these  changes  on  DTC  pa¬ 
rameters. 

The  DTC  concept  includes  several  cate¬ 
gories  of  cost  controls. 

•  Design  to  Unit  Production  Cost 
(DTUPC).  This  was  the  original  DTC 
application,  and  conceptually  the  easiest 
to  understand  and  apply.  By  Milestone 
II,  the  Program  Manager  usually  has  es¬ 
tablished  a  DTUPC  estimate  stated  in 
terms  of  a  selected  base  year’s  dollars, 
production  rate  and  total  buy,  and  pro¬ 
duction  start  date. 

•  Design  to  Operating  and  Support 
Criteria  (DTOSC).  Approved  values  for 
selected  O&S  elements  expressed  either 
in  dollars  or  by  other  measurable  fac¬ 
tors,  such  as  number  of  maintenance 
personnel,  spares,  fuel,  and  others  such 
as  resource  consumption,  reliability, 
and  maintainability. 

•  The  Army  also  reo,uires  that  the 
DTC  program  be  implemented  on  soft¬ 
ware  programs  with  a  development  cost 
of  $40M  or  more. 

Originally,  DTC  was  applied  only  to 
major  programs.  DoD  Directive  4243.3 
has  expanded  the  scope  of  the  process 
by  stating  that  the  management  and 
procurement  principles  are  equally 
valuable  for,  and  should  be  applied  to. 


the  acquisition  of  systems  below  the 
DAB  level.  The  criteria  for  imple¬ 
menting  DTC  on  less  than  major  pro¬ 
grams  is  that  the  program  have  a  devel¬ 
opment  design  requirement  and  that  the 
predicted  production  cost  be  $40M  or 
more.  DTC  goals  shall  be  established 
and  controlled  within  DoD  components 
for  these  systems  in  a  similar  manner. 
Approval  authority  for  cost  goals  and 
changes  to  the  goals  will  be  maintained 
at  a  management  level  above  the  pro¬ 
gram  or  subsystem  manager. 

The  applicability  of  DTC  has  also  been 
broadening  in  the  scope  of  costs  con¬ 
sidered.  Originally,  because  of  inade¬ 
quate  visibility  of  costs  in  the  O&S  ar¬ 
eas,  DTC  was  applied  only  to  production 
costs  -  specifically,  to  the  unit  produc¬ 
tion  cost  of  an  article  of  hardware. 
However,  the  ultimate  objective  is  to 
ensure  that  the  system  developed  will 
have  the  lowest  life-cycle  cost  consistent 
with  schedule,  support  and  performance 
requirements. 

The  DTC  goals  must  accurately  reflect 
the  critical  cost  factors  of  the  program, 
and  they  must  be  measurable,  manage¬ 
able,  and  useful  to  Government  and 
contractor  program  managers.  To  be 
useful,  the  cost  goals  must  be  stated  in 
constant  dollars  for  some  specified  base 
year.  Inflation  or  deflation  indices  re¬ 
quired  to  convert  then-year  to  baseline- 
year  dollars  should  be  specified  when 
the  goal  is  established.  In  addition,  it  is 
necessary  to  identify  ’production  quanti¬ 
ties  and  rates  and  the  delivery  schedule. 
Since  very  few  weapon  system  programs 
proceed  through  development  and  pro¬ 
duction  unchanged,  it  is  important  to 
identify  procedures  and  factors  (such  as 
learning  curves)  that  can  measure  the 
progress  toward  achieving  DTC  goals  if 
modifications  are  made  in  the  produc¬ 
tion  quantity  rate  or  schedule. 

The  DTC  goals  discussed  above  are  best 
suited  for  programs  with  relatively  large 
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production  quantities  except  for  soft¬ 
ware  programs.  The  DTC  concept 
strategy  can  be  effectively  applied  to 
one  of  a  kind  system  also,  but  it  must 
be  tailored.  In  these  types  of  programs, 
goals  different  from  flyaway  or  unit 
production  cost  can  be  used.  For  pro¬ 
grams  with  low  production  quantities  or 
proportionally  high  development  costs, 
total  acquisition  cost  would  be  a  better 
DTC  goal.  Programs  with  high  O&S 
costs  in  proportion  to  the  acquisition 
amount  would  call  for  DTC  controls  on 
the  total  life-cycle  cost.  The  establish¬ 
ment  of  cost  goals,  the  tracking  of  these 
goals  and  an  active  program  to  remain 
within  the  goals  is  especially  critical  in  a 
Joint  Program  where  budgeting  and  fi¬ 
nancial  activities  are  more  complex. 

Issue  5  -  Incentives.  Incentives  repre¬ 
sent  a  contractual  strategy  to  reward  the 
contractor  for  meeting  or  exceeding  de¬ 
fined  goals  and,  in  some  cases,  to  pe¬ 
nalize  the  contractor  for  failure  to  meet 
goals  by  not  giving  them  the  award  fee. 
Incentives  can  be  applied  to  any  system 
or  acquisition  characteristic,  including 
cost,  schedule,  performance,  producibil- 
ity,  reliability,  maintainability,  and 
quality,  and  they  can  be  applied  at  any 
phase  of  the  program. 

An  incentive  contract  is  used  to  moti¬ 
vate  the  contractor  to  meet  or  better 
target  levels  when  there  is  uncertainty 
about  the  outcome  and  the  contractor 
has  some  control  over  the  outcome. 

Most  incentive  contracts  involve  cost 
factors,  as  identified  by  the  contract 
type,  e.g.,  Cost  Plus  Incentive  Fee 
(CPIF)  and  Fixed  Price  Incentive  Firm 
(FPIF).  However,  an  increasing  number 
of  incentive  arrangements  are  based  on 
characteristics  other  than  cost,  particu¬ 
larly  award  fees  and  various  forms  of 
warranties  and  guarantees. 

There  are  two  broad  categories  of  con¬ 
tracts:  cost-reimbursable  and  fixed- 


price.  For  cost-reimbursable  contracts, 
the  contractor  provides  best  efforts  to 
meet  the  contract  terms  and  conditions 
and  the  Government  pays  all  of  the  al¬ 
lowable  costs  that  meet  the  test  of  rea¬ 
sonableness.  Risks  to  the  contractor  are 
minimal.  For  firm  fixed  price  contracts, 
the  contractor  must  provide  the  required 
product  or  service  at  a  predetermined 
price,  regardless  of  the  actual  cost. 
Contractor  risks  are  much  more  severe. 
Cost-Plus-Fixed-Fee  (CPFF)  and  the 
Firm-Fixed-Price  (FFP)  contracts  rep¬ 
resent  the  boundaries  of  the  contract- 
type  spectrum  with  respect  f>  the  con¬ 
tractor  risk.  Within  these  boundaries, 
there  are  a  number  of  possible  varia¬ 
tions.  The  following  are  three  of  the 
more  common  contract  forms  with  in¬ 
centive  features: 

•  Cost  Plus  Incentive  Fee  (CPIF). 
Used  in  advanced  engineering,  systems 
development,  and  first  production  con¬ 
tracts  when  uncertainties  of  performance 
preclude  a  fixed-price  contract  but  are 
not  so  great  as  to  require  a  cost-plus- 
fixed-fee  contract.  A  target  cost  and  a 
target  fee  are  established,  together  with 
a  minimum  and  maximum  fee.  Cost 
overruns  and  underruns  are  shared  in 
accordance  with  a  negotiated  formula 
until  the  minimum  or  maximum  fee  is 
reached.  There  is  no  ceiling  price. 

•  Fixed  Price  Incentive  Firm  (FPIF). 
Used  in  much  the  same  way  as  CPIF, 
but  where  there  is  less  uncertainty  in 
establishing  a  total  ceiling  price.  The 
FPIF  has  the  same  characteristics  as 
CPIF  except  that  a  ceiling  price  is  es¬ 
tablished  and  there  are  no  minimum  or 
maximum  fees  and  there  are  no  mini¬ 
mum  or  maximum  fees  negotiated. 

0  Cost  Plus  Award  Fee  (CPAF).  A 
cost-reimbursement  contract  with  a 
fixed  (base)  fee  and  an  award-fee  pool. 
Some  or  all  of  the  award-fee  pool  is 
paid  to  the  contractor  as  a  reward  for 
achieving  performance  in  designated 
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areas  above  minimum  acceptable  levels. 
Management  and  performance  are  typi¬ 
cal  areas.  The  underlying  theory  of  the 
award  fee  is  to  have  the  contractor  earn 
extra  profit  rather  than  negotiate  it. 

Within  each  of  these  three  major  types 
there  are  numerous  variations,  such  as 
varying  share  ratios  and  successive  tar¬ 
gets.  In  addition,  there  are  multiple- 
incentive  contracts,  which  attempt  to 
balance  performance,  schedule,  and  cost 
objectives  and  risks. 

Determining  the  need  for  an  incentive 
contract,  and  the  type  to  be  used,  de¬ 
pends  on  an  accurate  assessment  of  pro¬ 
gram  risks.  When  risk  is  minimal  and 
uncertainties  are  not  extreme,  a  fixed- 
price  contract  may  be  appropriate,  with 
or  wthout  incentives.  Cost-type  con¬ 
tracts  are  employed  in  greater-risk  situ¬ 
ations,  typically  in  the  research  and  de¬ 
velopment  phases,  when  cost  estimates 
are  highly  imprecise  or  technical  and 
other  uncertainties  do  not  permit  accu¬ 
rate  assessment  of  future  performance. 
From  an  acquisition  strategy  perspective, 
the  Program  Manager  must  act  as  fol¬ 
lows: 

1.  Determine  if  an  incentive  contract 
form  is  a  suitable  alternative  for  each 
phase. 

2.  Acquire  resources  and  data  to  in¬ 
vestigate  incentive  potential  further. 

3.  Select  applicable  incentive  forms  for 
each  phase  for  selected  cost/  perfor¬ 
mance/schedule  parameters. 

4.  Establish  basic  guidelines  for  en¬ 
tering  into  final  contract  negotiations. 

Issue  6  -  Make-or-Buv.  Make-or-buy, 
in  its  precise  procurement  meaning, 
refers  to  the  program  that  identifies 
(and  subsequential  obtains)  the  major 
components,  assemblies,  and  subassem¬ 
blies  to  be  manufactured  by  the  con¬ 


tractor’s  own  facilities  and  those  which 
will  be  obtained  elsewhere  by  subcon¬ 
tract.  "Make"  items  can  be  produced  by 
the  contractor  or  its  affiliate,  subsidiary, 
or  division;  "buy"  items  come  from 
subcontractors  or  suppliers. 

The  make-or-buy  decision  recognizes 
that  few,  if  any,  contractors  can  or  want 
to  fabricate  all  of  the  many  components 
needed  for  a  sophisticated,  complex 
major  weapon  system  in  the  time  re¬ 
quired,  within  cost  limits,  and  at  the  re¬ 
quired  quality  level.  "Buy"  decisions 
result  in  the  inclusion  of  subcontractors 
and  suppliers  in  the  program.  Subcon¬ 
tractor  management  can  confront  the 
Program  Manager  with  a  new  set  of 
problems.  Other  areas  that  the  make- 
or-buy  process  can  affect  are  associated 
with  social  legislation  goals  such  as  the 
use  of  small,  women-owned  or  minor¬ 
ity-owned  business  on  Federal  contracts. 
In  general,  make-or-buy  seeks  to  ac¬ 
complish  the  following: 

•  Assure  the  lowest  program  costs 
commensurate  with  necessary  system  re¬ 
quirements 

»  Restrain  unfair  prime  or  major 
contractor  growth  into  areas  where  a 
sufficient  mobilization  base  and  cost 
information  exists 

0  Effectively  use  Government-owned 
facilities 

0  Aid  implementation  of  National  so¬ 
cial  policies. 

Although  make-or-buy  considerations 
normally  focus  on  the  narrower  pro¬ 
curement-related  definition.  Program 
Managers  should  be  aware  of  other  types 
of  make-or-buy  alternatives  that  have  a 
distinct  effect  on  the  selection  and  ex¬ 
action  of  acquisition  strategies.  These 
alternatives  are  described  in  the  follow¬ 
ing  subsections. 
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Early  in  every  program,  the  Program 
Manager  must  conduct  an  analysis  that 
permits  selecting  the  best  method  to 
satisfy  mission  requirements: 

•  New  development  program.  The 
choice  to  "make"  a  new  system  is  usually 
the  most  costly  and  involves  the  longest 
time  for  equipment  deployment. 

•  Modification  of  existing,  other  ser¬ 
vices,  or  foreign  items.  This  alternative 
combines  "make"  and  "buy." 

•  Product  improvement.  This  alter¬ 
native  exploits  the  growth  potenti?'  in¬ 
herent  in  already  developed  systems, 
thereby  also  mixing  some  "make"  with 
"buy." 

•  Purchase  of  existing  military  (or 
commercial)  domestic  or  foreign  items. 
This  “buy"  alternative  can  provide  low- 
cost,  quick  response  to  some  require¬ 
ments. 

The  effects  of  this  issue  on  program 
planning,  implementation,  and  success 
are  profound.  In  this  alternative,  "make" 
refers  to  using  GFE;  "buy"  refers  to 
choosing  GFE.  Significant  pressures  ex¬ 
ist  in  the  following  areas: 

o  Benefit.  GFE  can  lower  life-cycle 
costs,  for  three  reasons: 

-Development  should  be  complete. 
-There  are  production  advantages 
due  to  larger  purchases. 

-Standardization  and  commonality 
advantages  should  contribute  to  support 
cost  savings. 

«  Risk.  The  use  of  GFE  can  increase 
program  technical  risk  (if  GFE  is  not 
compatible  or  does  not  meet  perfor¬ 
mance  guarantees);  schedule  risk  (if 
GFE  is  late  or  defective);  and  cost  risk 
(if  GFE  shortcomings  or  late  deliveries 
result  in  program  delays  or  changes). 
Some  participants  in  the  DD-(  53  De¬ 


stroyer  Program  attribute  the  program’s 
success  to  the  conscious  strategy  of 
minimizing  the  use  of  GFE;  other  pro¬ 
grams  ( e.g F-5E  International  Fighter) 
realized  the  full  benefits  of  extensive 
use  of  GFE. 

Government  offices  must  analyze  the 
proposed  make-or-buy  programs  on  the 
the  basis  of  cost,  cost  realism,  ease  of 
management  and  overall  benefit  to  the 
Government  in  accordance  with  the  re¬ 
quirements  of  the  April  1984,  FAR 
15.707  and  DoD  FAR  Supplement. 

From  the  contractor’s  viewpoint,  the 
following  are  the  reasons  for  "make"  or 

"buy": 

Make 

•  Develop  capability,  people,  process 

•  Use  idle  capacity 

•  Maintain  work  force  for  future 

•  Retain  ability  for  close  supervision 

•  Facilitate  process  and  change  con¬ 
trol 

•  Minimize  transportation  problems 

•  Retain  confidential  designs  or  pro¬ 
cess  secrets 

•  Reduce  dependence  on  outside 
sources  of  supply 

Buy 

•  Technical  know-how  lacking 

«  Investment  in  equipment,  tools,  or 
equipment  not  justifiable 

•  Volume  required  too  larg  or  too 
small 

•  Risky  market  demands  better  han¬ 
dled  by  specialty  supplier 

o  Better  quality  available  from  outside 
supplier 

•  Basis  provided  for  checking  in- 
house  costs 

•  Patents  or  trade  secrets  involved 

•  Reciprocity  possible 

Issue  7  -  Multiyear  Contracting.  Multi¬ 
year  Contracting  (MYC)  or  Multiyear 
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Procurement  (MYP)  is  a  method  of  ac¬ 
quiring  more  than  one  year’s,  but  not 
more  than  five  years’  requirements,  un¬ 
der  one  contract.  Each  program  year  is 
budgeted  and  funded  annually,  but  the 
commitment  is  for  at  least  several  years. 

Single-year  contracting  for  major  sys¬ 
tems  has  been  the  usual  method  of  ac¬ 
quisition  for  many  years.  The  quantities 
are  authorized  and  the  funds  are  appro¬ 
priated  annually.  Contractors  are  not 
willing  to  commit  to  expenditures  for 
long-lead  items,  economical-order 
quantities,  or  equipment  investment 
when  they  are  not  sure  of  future  busi¬ 
ness.  The  DoD,  industry,  and  GAO 
have  all  stated  that  this  method  of  ac¬ 
quisition  is  inefficient. 

MYC  can  be  more  efficient  and  less 
costly  than  single-year  procurement  by 
allowing  or  encouraging  the  following: 

•  quantity  purchases  for  out-year  de¬ 
liverables 

-Materials 

-Components 

-Subsystems 

-Subassemblies 

-Assemblies 

•  Efficient  labor  utilization  over  the 
life  of  the  contract 

•  Contractor  capital  investment  (e.g., 
purchase  of  tooling  or  facilities  to 
achieve  cost  efficiencies.) 

The  benefits  of  MYC  are  to  reduce 
procurement  costs  and  provide  incen¬ 
tives  for  industry  investment.  MYC  has 
been  favorably  viewed  by  Congress,  in¬ 
dustry,  and  the  military.  The  Military 
Departments  and  industry  have  cited  fa¬ 
vorable  experience  to  date, 

•  Cost  savings  are  realized  by  the  use 
of  MYC  versus  single-year  procurements 
depending  on  the  depth  to  which  MYC 


is  applied,  i.e .,  materials,  components, 
subassemblies,  or  assemblies. 

•  Business  is  stimulated  because  more 
economical  purchases  from  vendors  and 
subcontractors  are  permitted;  an  incen¬ 
tive  to  invest  in  new  equipment  is  pro¬ 
vided;  and  there  is  orderly  buildup,  sta¬ 
bility,  and  scaling  back  of  personnel. 

•  A  potential  for  meeting  surge  re¬ 
quirements  develops  in  the  second  and 
subsequent  years  of  the  contract  by 
virtue  of  the  assured  existence  of  the 
suppliers,  subcontractors,  and  vendors. 

The  reasons  for  selecting  MYC  are  to 
reduce  costs,  schedule  activities  more 
productively,  and  provide  incentives  for 
industry  investment.  If  the  program  is 
not  amenable  to  MYC  after  it  is  started, 
the  option  to  terminate  the  MYC  could 
entail  substantial  cancellation  liability. 
Guidelines  for  MYC  compatability  were 
promulgated  by  the  Deputy  Secretary  of 
Defense  in  a  Policy  Memorandum  (1 
May  1981). 

The  process  of  deciding  to  use  or  not  to 
use  a  multiyear  procurement  for  pro¬ 
duction  programs  as  well  as  how  best  to 
tailor  and  structure  MYP  requires  man¬ 
agement  judgment.  The  following  cri¬ 
teria  have  been  prepared  as  guidelines 
for  decision-makers.  The  criteria  are  to 
be  considered  in  a  comparative  bene¬ 
fit/risk  analysis  format  where  criterion  1 
below,  represents  the  benefit  factor,  and 
criteria  2  through  6  represent  risk  fac¬ 
tors. 

Guidelines  for  MYC 

1.  Benefit  to  the  Government.  A 
multiyear  procurement  should  yield 
substantial  cost  avoidance  or  other  ben¬ 
efits  when  compared  to  conventional 
annual  contracting  methods.  MYC  pro¬ 
posals  with  greater  risk  to  the  Govern¬ 
ment  should  demonstrate  increased  cost 
avoidance  or  other  benefits  over  those 
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with  lower  risk.  Savings  can  be  defined 
as  significant  either  in  terms  of  absolute 
dollars  or  percentage  of  total  cost. 

2.  Stability  of  Requirement.  The 
minimum  need  ( e.g .,  inventory  or  ac¬ 
quisition  objective)  for  the  production 
item  or  service  is  expected  to  remain 
unchanged  or  vary  only  slightly  during 
the  contemplated  contract  period  in 
terms  of  production  rate,  fiscal  year 
phasing,  and  total  quantities. 

3.  Stability  of  Funding.  There  should 
be  a  reasonable  expectation  that  the  pro¬ 
gram  is  likely  to  be  funded  at  the  re¬ 
quired  level  throughout  the  contract  pe¬ 
riod, 

4.  Stable  Configuration.  The  item 
should  be  technically  mature,  have  com¬ 
pleted  RDT&E  (including  development 
testing  or  equivalent)  with  relatively  few 
changes  in  item  design  anticipated  and 
underlying  technology  should  be  stable. 
This  does  not  mean  that  changes  will  not 
occur  but  that  the  estimated  cost  of  such 
changes  is  not  anticipated  to  drive  total 
costs  beyond  the  proposed  funding  pro¬ 
file. 

5.  Degree  of  Cost  Confidence.  There 
should  be  a  reasonable  assurance  that 
cost  estimates  for  both  contract  costs 
and  anticipated  cost  avoidance  are  real¬ 
istic.  Estimates  should  be  based  on 
prior  cost  history  for  the  same  or  similar 
items  or  proven  cost  estimating  tech¬ 
niques. 

6.  Degree  of  Confidence  in  Contractor 
Capability.  There  should  be  confidence 
that  the  potential  contractor(s)  can  per¬ 
form  adequately,  both  in  terms  of  Gov¬ 
ernment  furnished  items  (material,  data, 
etc.)  and  their  firm’s  capabilities.  Po¬ 
tential  contractors  need  not  necessarily 
have  previously  produced  the  item. 

Issue  8  -  Phased.  Acquisition.  Phased 
acquisition  of  major  systems  must  now 


include  a  Low-Rate  Initial  Production 
(LRIP)  Phase  in  transitioning  from  Full 
Scale  Development  to  Production  and 
Deployment,  including  Operational  Test 
and  Evaluation  (OT&E)  under  the  aus¬ 
pices  of  the  Director,  Defense  Opera¬ 
tional  Test  and  Evaluation.  The  premise 
is  that  production  articles  can  benefit 
from  development  design  changes  and 
test  results  and  from  initial  low-rate 
production  and  early  operating  experi¬ 
ence,  such  that  it  is  worthwhile  to  delay 
high-rate  production  and  full  deploy¬ 
ment  of  the  system  for  some  period. 
The  system  life-cycle  cost  is  expected  to 
be  lower  because  of  corrections  of  defi¬ 
ciencies  early  in  production  and  de¬ 
ployment  and  the  reduced  need  to  cor¬ 
rect  production  articles  on  the  produc¬ 
tion  line  and  in  the  field.  The  LRIP 
phase  also  allows  sufficient  time  for  a 
second  production  source  to  produce  an 
"educational"  lot,  while  holding  the  pri¬ 
mary  source  from  moving  too  far  down 
the  learning  curve  and  obtaining  a  large 
competitive  advantage. 

Phased-acquisition  alternatives  might 
also  include  consideration  of  warm  pro¬ 
duction  base,  cold  production  base,  and 
production  breaks,  but  these  are  usually 
used  to  protect  production  sources  once 
a  system  has  been  produced  and  de¬ 
ployed.  For  the  consideration  of  Ac¬ 
quisition  Strategy,  this  section  will  focus 
on  LRIP. 

Phased  acquisition  addresses  the  problem 
of  an  immature  design  reaching  produc¬ 
tion  and  being  fielded  before  it  is  ready. 
The  transition  from  development  to  pro¬ 
duction  and  deployment  is  the  most  dif¬ 
ficult  activity  to  manage.  Concurrent 
activities  are  proceeding  in  testing,  cor¬ 
rection  of  design  deficiencies,  and  initial 
production  and  deployment  of  the  sys¬ 
tem.  Phased  acquisition  is  intended  to 
ensure  that  the  system  is  close  to  a  final 
production  article  before  full  production 
is  implemented.  It  addressed  the  prob¬ 
lem  of  overcoming  early  deficiencies 


discovered  in  design  and  testing  and  in 
the  field,  and  correcting  those  deficien¬ 
cies  prior  to  full  production  and  field 
deployment,  thereby  causing  the  least 
perturbation  to  the  overall  procurement 
and  deployment  plan. 

Phased  acquisition  is  most  beneficial  for 
a  technologically  advanced,  highly  com¬ 
plex  weapon  system  for  which  time  is 
needed  to  mature  the  design  and  provide 
test  information  and  early  production 
and  field  deployment  experience,  and 
where  initial  low-rate  production  facili¬ 
tates  achieving  the  program  objectives. 
It  provides  design,  test,  producibility, 
and  operational  information  while  hold¬ 
ing  down  the  cost  of  production  line  and 
field  retrofit.  It  can  also  be  used  to 
initiate  a  competition  using  a  second 
production  source.  In  formulating  an 
acquisition  strategy,  the  selection  and 
timing  of  an  initial  production  rate, 
whither  sole-source  or  competitive,  and 
the  time  allowed  to  transition  to  full  rate 
must  be  appropriately  integrated  with 
the  design,  test,  and  production  activi¬ 
ties. 

Phased  acquisition  requires  the  follow¬ 
ing: 

•  Clear  management  direction  that 
this  is  the  approach  that  will  be  pursued 

•  A  tendency  toward  an  austere  initial 
development 

•  Intense  early  performance  testing 
and  operations  to  obtain  data  to  mature 
the  design 

•  Feedback  and  analysis  of  early  test 
and  operational  data  to  mature  the  de¬ 
sign  prior  to  full  production 

•  Realism  concerning  the  technology 
assessment  and  schedule  flexibility 

Phased  acquisition  provides  an  opportu¬ 
nity  to  obtain  more  test  data  and  early 


production  and  field  operating  data  with 
which  to  correct  deficiencies  prior  to 
high-rate  production.  It  provides  early 
visibility  and  timely  information  to  re¬ 
veal  and  correct  performance  and  sup¬ 
port  problems;  at  the  same  time  it  re¬ 
duces  the  number  of  units  requiring 
retrofit  in  production  and  in  the  field. 
It  also  provides  some  flexibility  in  ob¬ 
taining  more  information  about  uncer¬ 
tainties  in  performance  and  cost,  while 
providing  belter  information  to  enable 
more  informed  decisions.  When  high 
rate  is  approved  more  operationally 
ready  articles  are  delivered  to  the  field 
and  life-cycle  cost  is  lower.  Modifica¬ 
tions  to  fielded  articles  are  more  expen¬ 
sive  than  modifications  made  prior  to 
production;  configuration  management  is 
more  difficult  when  more  deficiencies 
are  being  corrected;  and  inventories  re¬ 
quire  the  stocking  of  a  greater  variety  of 
part  types  and  more  parts  if  more  defi¬ 
ciencies  are  being  corrected.  Therefore, 
even  though  the  full  operational  capa¬ 
bility  schedule  may  appear  to  be  longer, 
the  date  at  which  a  specific  level  of  ca¬ 
pability  is  achieved  might  actually  be 
earlier. 

Phased  acquisition  requires  a  longer  pro¬ 
gram  schedule  and  thus  delays  full  op¬ 
erational  deployment.  Earlier  produc¬ 
tion  units  will  be  more  costly  because  of 
lower  production  rate.  During  periods 
of  high  inflation,  time  delays  could  seri¬ 
ously  perturb  the  funding  stability  of 
the  program  and  increase  costs.  Longer 
exposure  to  annual  incremental  funding 
could  jeopardize  the  continuation  of  the 
program,  for  various  reasons  (<?.£'.,  tech¬ 
nical,  political)  as  it  moves  through  the 
acquisition  process. 

Issue  9  -  Preplanned  Product  Improve- 
menj..  Preplanned  Product  Improvement 
(P3!)  makes  it  possible  to  develop  and 
field  a  new  weapon  system  while  im¬ 
provements  to  that  system  are  being 
planned  for  phased  integration.  P3I  has 
been  defined  as  a  systematic  and  orderly 
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acquisition  strategy  beginning  at  the 
system*.*:  conrept  phase  to  facilitate  evo- 
lutionar v.  cost-effective  upgrading  of  a 
system  througliout  the  life  cycle  to  en¬ 
hance  readiness,  ava'labil ity ,  and  capa¬ 
bility. 

Since  the  early  1950s,  the  acquisition 
philosophy  fc;  weapon  systems  has  been 
predominantly  one  of  pushing  the  state 
of  the  art.  Once  a  threat  has  been  vali¬ 
dated,  the  technology  for  countering 
that  threat  is  devalued,  thereby  en¬ 
abling  a  weapon  system  to  be  developed 
and  deployed.  If  a  vechnoiogy  or  threat 
change  occurs  during  the  development 
of  the  weapon  systr.a.  one  of  two  ac¬ 
tions  can  be  taken  in  response  to  the 
change:  (1)  redesign  the  weapon  system 
to  incorporate  the  change,  or  (2)  con  • 
tinue  the  development  to  deployment 
originally  designed  and  plan  to  modify 
the  system  later  in  the  field. 

Both  of  these  approaches  can  be  costly 
to  implement,  and  complete  success  in 
meeting  a  new  threat  may  *  ot  be 
achieved.  On  the  other  hand,  starting 
the  development  with  a  system  require¬ 
ment  designed  to  meet  probable  future 
threats  may  induce  unacceptable  risks  if 
the  required  technology  is  not  available. 
P3I  affords  a  means  of  meeting  the  cur¬ 
rent  threat  and  making  plans  for  meet¬ 
ing  probable  future  threats  or  improving 
the  system  as  technology  becomes 
available,  without  having  to  develop  a 
new  system. 

P3I  also  addresses  a  related  problem  - 
that  of  trying  to  incorporate  a  number 
of  available  but  new  technologies  all  at 
once.  The  technological  problems  that 
can  result  from  trying  to  do  too  much 
too  soon  can  lead  to  serious  management 
and  resource  difficulties  as  unexpected 
interface,  reliability,  support,  and  other 
deficiencies  emerge. 

Product  improvement  (PI)  is  sometimes 
confused  with  P3I,  as  is  Planned  Product 


Improvement  (PPI).  Product  improve¬ 
ment  is  applied  when  a  system  is  in  the 
field  and  changes  or  corrections  must  be 
incorporated  to  overcome  problems. 
Planned  product  improvement  represents 
a  change  to  the  system  that  is  generally 
anticipated  but  that  the  basic  system  was 
not  originally  designed  to  accommodate. 
Examples  include  the  upgradings  of  the 
Polaris,  Minuteman,  and  Pershing  mis¬ 
sile  weapon  systems. 

P3I  differs  from  PI  and  PPI  in  that  it  is 
planned  evolutionary  growth.  The  need 
for  eventual  modification  is  recognized 
during  the  early  development  stages,  and 
the  acquisition  strategy  is  designed  to 
include  provisions  for  ensuring  that 
these  modifications  can  be  effectively 
introduced.  Specific  design  strategy  ap¬ 
plicable  to  P3I  include  modular  design,  a 
carefully  architectured  interface  system, 
and  inclusion  of  reserves  for  space, 
weight,  power,  and  cooling.  The  system 
development  process  must  include 
strategy  and  plans  for  communicating 
system  growth  requirements  and  for 
identifying  new  technological  opportu¬ 
nities. 

The  following  advantages  ssult  from  an 
effective  implementation  of  P3I: 

•  Responsiveness  to  threat  changes 
and  future  technology  development 

•  Earlier  IOC  date  for  baseline  system 

•  Reduced  development  risks 

•  Potential  for  subsystem  competition 

•  Enhanced  operational  capability  for 
"final"  system 

•  Stimulation  for  laboratory  and 
IR&D  research 

•  Increased  effective  operational  life 
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Possible  disadvantages  of  using  the  PSI 
concept  include: 

•  Increased  nonrecurring  cost  during 
initial  development 

•  Increased  technical  requirements  iu 
such  areas  as  space,  weight,  power,  and 
cooling 

•  Increased  complexity  in  configura¬ 
tion  management 

•  Vulnerability  to  "gold  plating"  criti¬ 
cism  and  funding  cuts 

•  Compounding  of  the  system  man¬ 
agement  problem  because  of  parallel  de¬ 
velopments 

•  Interference  with  the  orderly  devel¬ 
opment  and  implementation  of  effective 
support  plans  and  procedures 

Issue  10  -  Source  Selection.  Source  se¬ 
lection  is  the  process  wherein  the  re¬ 
quirements,  facts,  recommendations,  and 
Government  policy  relevant  to  an  award 
decision  in  a  competitive  procurement 
of  a  system/project  are  examined  and 
the  decision  is  made. 

DoDD  4105.62,  Selection  of  Contractual 
Sources  for  Major  Defense  Systems,®^ 
emphasizes  that  the  prime  objectives  of 
the  process  are: 

•  To  select  contractors  that  can  best 
meet  the  Government’s  needs,  pursuant 
to  the  solicitation 

•  To  ensure  the  impartial,  equitable, 
and  comprehensive  evaluation  of  each 
offeror’s  proposal 

•  To  ensure  the  procedures  employed 
for  source  selection  are  flexible  and  tai¬ 
lored  to  the  requirements  of  the  specific 
acquisition  so  as  to  minimize  the  cost  of 
the  process  to  Government  and  industry 


The  1985  revision  of  DoDD  4105.62  in¬ 
cludes  a  major  section  dealing  with  ac¬ 
quisition  strategy.  An  important  point  is 
that  the  stratagem  is  acknowledged  to  be 
evolutionary,  reaching  a  state  of  defini¬ 
tion  sufficient  to  manage  all  elements  of 
the  acquisition  prior  to  the  release  of  the 
initial  solicitation. 

Source  selection  addresses  a  rather 
clearly  defined  problem,  faced  several 
times  during  the  life  of  a  system  pro¬ 
gram:  which  contractor  source  or  sources 
will  provide  the  most  beneficial  product 
or  service  to  the  Government.  Source 
selection  itself  may  present  problems  for 
the  Program  Manager  in  terms  of  exe¬ 
cution,  but  its  applicability  is  not  at  is¬ 
sue.  Although  there  are  alternative 
forms  of  source  selection,  contracting 
specialists  will  help  recommend  the  ap¬ 
propriate  form  for  each  solicitation  on 
the  basis  of  such  factors  as  program 
size,  technical  complexity,  and  a  number 
of  sources.  Source  selection  is  especially 
critical  at  Milestones  I  and  II;  Milestone 
III  and  subsequent  production  source 
selections  can  be  important  if  a  multi¬ 
ple-source  strategy  is  followed  to  main¬ 
tain  competition. 

Several  criteria  affect  the  format  of  the 
source-selection  process: 

•  Clarity  and  completeness  of  the  re¬ 
quirement.  Competition  for  products 
(and  services)  that  are  similar  to  de¬ 
scribe  and  price  may  result  in  a  formal 
advertising  approach,  whereas  negotiated 
procurement  is  usually  chosen  in  more 
complex  solicitations. 

•  Size  of  procurement.  Full  DoDD 
4105.62  procedures  are  required  for 
major  programs.  Lesser  programs  can 
use  more  streamlined  service  processes. 

«  Urgency  of  requirements.  Occa¬ 
sionally,  the  military  necessity  enables 
extraordinary  tailoring  of  the  selection 
process. 
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Care  must  be  taken  to  ensure  that  the 
essential  objective  of  an  impartial,  eq¬ 
uitable,  and  comprehensive  evaluation  is 
not  compromised.  Because  of  this,  the 
Program  Manager  is  strongly  urged  to 
have  the  advice  and  counsel  of  pro¬ 
curement  officials  in  planning  or  exe¬ 
cuting  source  selections. 

The  Program  Manager’s  major  analytical 
task  is  to  ensure  that  the  source-selec¬ 
tion  approach  provides  the  best  possible 
communication  of  what  the  Government 
needs  and  what  industry  can  provide. 
The  following  are  some  of  the  ways  in 
which  this  communication  process  can 
be  helped. 

•  Thorough  risk  analysis,  This  is  un¬ 
doubtedly  the  key  first  step  once  the  re¬ 
quirements  have  been  established  and 
validated.  The  analysis  will  identify  the 
critical  areas  of  technical  and  cost  sensi¬ 
tivity  for  inclusion  in  the  solicitation 
package. 

•  Integrated  and  simultaneous  prepa¬ 
ration  of  the  RPP,  SSP  with  evaluation 
criteria,  and  a  model  contract. 

•  Release  of  draft  RFPs  to  industry 
well  in  advance  of  formal  release  date. 

«  Use  of  "Internal  Review  Boards"  at 
field  and  system  command  levels. 

4.0  SUMMARY 

The  selection  and  proper  adjustment  of 
a  sound  acquisition  strategy  can  result  in 
the  much  more  efficient  execution  of 
the  already  difficult  joint  program. 
Major  points  presented  above  include: 

0  All  programs  require  a  tailored  and 
modifiable  acquisition  strategy; 

0  Acquisition  strategy  is  normally 
considered  the  plan  for  program  execu¬ 
tion,  while  the  acquisition  plan  is  more 


activity  oriented,  although  the  three  ser¬ 
vices  differ  slightly; 

0  The  evaluation  of  technical  risk  and 
its  impact  on  the  acquisition  strategy  is 
of  constant  concern  to  the  Program 
Manager;  and 

0  The  following  acquisition  issues 
were  addressed: 

-Competition, 

-Make  or  Buy, 

-Concurrency, 

-Multiyear  Contracting, 

-Data  Rights, 

-Phased  Acquisition, 

-Design  to  Cost, 

-Preplanned  Product  Improvement, 
-Incentives,  and 
-Source  Selection. 

FOOTNOTKS  AND  RKI-KRKNCKS: 

1/  "Program  Manager'!  Notebook,"  Detinue  Syr- 
tome  Management  College,  October,  1986,  p.  3.1c. 

2/  "Program  Manager1!  Notebook,"  Defense  Sy3 
terns  Management  Collage,  October  1985.  p.  3.1o. 

2/  Army  Regulation  Alt  7U-1,  System  Acquisi¬ 
tion  Policy  and  Procedures,  12  November  19B6. 

4/  SECNAVINST  4200.33,  "Selection  of  Con¬ 
tractual  Sources  for  Department  of  the  Navy  De¬ 
fense  Systems." 

5/  SECNAVINST  4210.0,  "Acquisition  Policy." 

0/  "Acquisition  Strategy  Guide,"  Defense  Systems 
Management  College,  1  July  1984. 

7/  Defense  Systems  Management  College  Hand¬ 
book,  "Establishing  Competitive  Production 
Sources,"  August  1084. 

8/  DoD  Directive  4245.3,  "Design  to  Cost,"  April 
1983. 

9/  DoD  Directive  4105.62,  "Selection  of  Con 
tractual  Sources  for  Major  Defense  Systems," 
September  1985. 
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CHAPTER  5 

PROGRAM  REVIEWS 


1.0  SYNOPSIS 

This  chapter  discusses  the  reviews  con¬ 
ducted  by  the  services  and  DoD  that 
evaluate  programs  during  the  acquisition 
of  military  systems.  A  joint  acquisition 
program  manager,  in  particular,  must 
understand  that  the  continued  existence 
and  progression  of  a  program  from  one 
acquisition  phase  to  another  will  be  the 
direct  result  of  successfully  accomplish¬ 
ing  the  reviews.  Program  review  ratio¬ 
nale  is  provided  in  section  2,0,  Joint 
program  milestones  and  reviews  are 
presented  in  section  3.0  and  the  flexi¬ 
bility  of  Milestones  II  and  III  is  dis¬ 
cussed  in  section  4.0.  Next,  specialized 
management  for  selective  high-priority 
programs  is  presented  in  section  5.0. 
Service  program  reviews  are  highlighted 
in  section  6.0.  Preparation  for  the  De¬ 
fense  Acquisition  Board  (DAB)  is  pre¬ 
sented  in  section  7.0,  followed  by  a 
discussion  of  program  assistance  and 
support  in  section  8.0.  Finally,  a  sum¬ 
mary  of  the  chapter  is  provided  in  sec¬ 
tion  9.0 

2.0  PROGRAM  REVIEW  RATIONALE 

The  objectives  of  the  program  reviews 
are  to  determine  that  an  acquisition  pro¬ 
gram  is  viable,  valid  and  cost  effective 
as  it  progresses  through  the  acquisition 
process.  The  reviews  present  opportu¬ 
nities  to  conduct  balanced  assessments  of 
the  risks  and  uncertainties  associated 
with  a  program  at  the  completion  of 
specific  acquisition  phases.  Not  only 
must  the  upper  echelons  of  authority  of 
DoD  and  the  lead  service  be  satisfied 
with  the  review  results,  but  also  those  of 
each  of  the  participating  services.  Com¬ 
pletion  of  preparatory  steps,  in  a  timely 
manner,  prior  to  a  program  review  is 
also  essential  and  varies  from  service  to 
service. 


Program  reviews  have  been  established 
to  be  conducted  at  specific  milestones  in 
the  acquisition  that  ensure  all  areas  of 
risk  and  uncertainty  of  a  program  are 
carefully  considered  before  a  commit¬ 
ment  is  made  to  proceed  to  the  next  ac¬ 
quisition  phase.  Risk  is  defined  as  the 
condition  of  having  outcomes  with 
known  probabilities  of  occurrence,  not 
certainty  of  occurrence.^  Areas  of  risk 
pertaining  to  a  program  may  include: 

•  Technical  Performance  Risk.  Will 
the  mcan-time-between-failures  be 
within  acceptable  limits? 

•  Schedule  Risk.  Is  the  acquisition 
schedule  adequate  considering  the  state- 
of-the-art  and  complexity  of  the  sys¬ 
tem? 

•  Cost  Risk.  Considering  the  current 
priority  of  the  program  will  newly  re¬ 
vised  cost  estimates  adversely  affect  the 
unit  costs  of  the  system? 

Uncertainty,  on  the  other  hand,  is  de¬ 
fined  as  the  condition  of  having  out¬ 
comes  with  unknown  probabilities  of 
occurrence.^  Areas  of  uncertainty  re¬ 
garding  a  program  may  include: 

•  Mission  Uncertainty.  Does  the 

threat,  as  originally  assessed,  still  exist? 
Does  the  mission  requirement  adequately 
identify  and  balance  or  mitigate  the 

threat? 

•  Technical  Uncertainly.  Are  the 

technical  objectives  of  the  system  feasi¬ 
ble  with  respect  to  the  time  and  re¬ 

sources  available  to  be  expended? 

•  Program  Uncertainty.  Is  the  acqui¬ 
sition  management  strategy  consistent 
with  program  goals  and  resources? 


•  Background  Uncertainty.  What  are 
the  factors  external  to  the  program,  e.g., 
change  in  national  goals,  change  in  po¬ 
litical  or  economic  climate,  change  in 
DoD  or  service  policy,  which  can  affect 
the  program?  Are  these  impacts  con¬ 
sistent  with  program  objectives  and  re¬ 
source  commitment? 

•  Logistic x  Uncertainty.  Will  the  sys¬ 
tem  be  supportable  at  deployment  under 
the  logistics  philosophy  and  strategy  in 
use? 

The  reviews  are  conducted  indepen¬ 
dently  of  the  Planning,  Programming, 
and  Budgeting  System  (PP13S)  process, 
and  evaluate  only  one  program  at  a 
time.  In  addition,  the  reviews  do  not 
attempt  to  assign  relative  precedence 
among  the  programs  reviewed  by  the  re¬ 
view  groups.  However,  during  the  mis¬ 
sion  conceptualization  and  requirement 
development,  a  determination  must  be 
made  of  the  importance  and  urgency  of 
the  proposed  program  and  of  the  costs 
involved  in  bringing  it  to  fulfillment. 
Those  parameters  will  dictate  the  level 
of  formal  Office  of  the  Secretary  of 
Defense  (OSD)  and  service  management 
attention.  Non-major  programs,  arc  also 
managed  according  to  the  precepts  of 
the  major  program  acquisition  direc¬ 
tives,  but  by  service-unique  methods. 

3.0  JOINT  PROGRAM  MILESTONES 
AND  REVIEWS 

DoD  Directive  S000.1  and  DoD  Instruc¬ 
tion  5000.2  of  12  March  1986-/-/  define 
the  milestones  for  major  acquisition 
program  reviews.  Figure  5-1-^  presents 
the  milestones  and  reviews  for  joint 
programs.  The  figure  also  identifies  the 
primary  documentation  involved  wtih 
each  milestone.  Major  aspects  of  each 
milestone  and  applicable  documentation 
are  discussed  further  below; 

Milestone  0  -  Mission  Need  Determina¬ 
tion 


•  The  mission  need  determination  is 
accomplished  in  the  PPBS  process  based 
on  the  proposed  joint  programs  Justifi¬ 
cation  of  Major  System  New  Starts 
(JMSNS)  that  is  submitted  with  the  lead 
service  Program  Objectives  Memoran¬ 
dum  (POM)  or  with  all  participating 
services  POMs  as  agreed  in  their  Mem¬ 
orandum  of  Agreement  (MOA). 

•  Subsequently,  SECDEF  provides  ap¬ 
propriate  program  guidance  in  a  SEC- 
DEF  Decision  Memorandum  (SDDM) 
that  will  authorize  the  initiation  of  the 
next  acquisition  phase,  including: 
establishment  of  program  goals  and 
thresholds,  reaffirming  established  needs 
and  program  objectives;  authorization  of 
exceptions  to  acquisition  policy;  and  di¬ 
rection  and  guidance  to  OSD,  OJCS,  and 
the  participating  services  for  the  next 
phase  of  the  acquisition.  Most  joint 
major  systems  new  starts  have  a  Defense 
Acquisition  Board  (DAB)  review,  from 
which  a  SDDM  is  generated.-^ 

Milestone  I  -  Requirement  Validation 

•  The  Joint  Program  Manager  will 
present  a  System  Concept  Paper  (SCP) 
and  Test  and  Evaluation  Master  Plan 
(TEMP)  to  the  Defense  Acquisition 
Board  (DAB)  for  review. 

-The  SCP  summarizes  the  results  of 
the  Concept  Exploration  Phase  up  to 
Milestone  I  and  discusses  the  joint  pro¬ 
gram  acquisition  strategy,  including  the 
identification  of  concepts  to  be  carried 
into  the  next  acquisition  phase 
(Demonstration  and  Validation),  and  the 
reasons  for  the  elimination  of  other 
concepts.  Also  included  are  the  goals, 
thresholds  arid  ranges,  to  be  achieved 
and  subsequently  reviewed  at  Milestone 
II.  See  Enclosure  4  to  DoD  Instruction 
5000.2  for  the  SCP  format.-^ 

-The  TEMP  defines  and  integrates 
the  test  objectives,  critical  issues,  system 
characteristics,  responsibilities,  re- 
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sources,  and  schedules  for  the  test  and 
evaluation  of  the  system.-^ 

Based  on  the  DAB  review,  SECDEF 
will  render  a  decision  that  will  establish: 
thresholds  and  objectives  to  be  met  and 
reviewed  at  the  next  milestone;  the  ac¬ 
quisition  strategy  for  the  recommended 
concepts  (including  the  nature  and  tim¬ 
ing  of  the  next  SECDEF  decision  point); 
and  a  dollar  threshold  that  cannot  be 
exceeded  to  carry  the  program  through 
the  next  milestone. 

Milestone  II  -  Program  Go  Ahead 

•  The  Joint  Program  Manager  will 
submit  a  Decision  Coordinating  Paper 
(DCP),  an  Integrated  Program  Summary 
(IPS),  when  required,  and  a  TEMP  to 
the  DAB  fa:  consideration. 

-The  DCP  is  a  top-level  summary 
document  that  identifies  alternatives, 
goals,  thresholds  and  threshold  ranges,  as 
appropriate.  See  Enclosure  4  to  DoD 
Instruction  5000.2  for  the  DCP  format 
which  is  identical  to  the  SCP  format.-^ 

-The  IPS  provides  more  specific 
information  on  the  program  and  should 
be  prepared  when  the  DAB  Chair  de¬ 
termines  that  the  DCP  lacks  information 
on  which  to  base  a  requisite  decision. 

-The  TEMP  submitted  at  Milestone 
I  will  be  updated  and  expanded,  as  ap¬ 
propriate,  and  should  define  the  T&E 
program  for  the  full-scale  development, 
for  consideration  by  the  DAB. 

•  In  addition,  a  Low  Rate  Initial  Pro¬ 
duction  (LRIP)  Report,  prepared  by  the 
Director,  Operational  Test  and  Evalua¬ 
tion  (DOT&E)  should  be  provided  to 
SECDEF  and  the  Congress  for  review,^ 

-The  LRIP  Report  is  an  assessment 
of  the  adequacy  of  the  OT&E  and  the 
effectiveness  and  suitability  of  a  weapon 
system  for  combat.  The  report  will  be 


reviewed  by  the  House  and  the  Senate 
Committees  on  the  Armed  Services  and 
Appropriations. 

*  Based  on  the  results  of  the  DAE 
and  Congressional  reviews,  the  SECDEF 
will  issue  an  SDDM  which  may  include 
a  decision  to  proceed  beyond  the  low 
rate  initial  production.  Also,  SECDEF 
may  advise  whether  a  DAB  review  will 
be  required  for  Milestone  III,  or  a 
(Service)  Systems  Acquisition  Review 
Council  (S)SARC  or  Navy  Program  De¬ 
cision  Meeting  (NPDM)  review  will 
suffice. 

Milestone  III  -  Production  Ratification 

•  The  Joint  Program  Manager  an  i  the 
DOT&E  will  submit  updated  documents 
cited  for  Milestone  II  above  to  SECDEF 
and  Congress,  if  a  DAB  review  will  be 
conducted  at  Milestone  III.  In  the  event 
that  Milestone  III  will  be  accomplished 
by  a  service  review,  the  Joint  Program 
Manager  and  the  DOT&E  will  submit 
the  documents  to  the  (S)SARC  or  NPDM 
chair,  as  appropriate. 

•  If  a  DAB  review  is  conducted, 
SECDEF  will  issue  an  SDDM  authoriz¬ 
ing  the  program  to  proceed  into  Rate 
Production.  In  the  event  a  service  re¬ 
view  is  conducted  the  Commander  of 
the  lead  service,  in  coordination  with 
the  participating  services,  will  issue  an 
appropriate  memorandum  similar  to  the 
SECDEF  SDDM. 

4.0  FLEXIBILITY  OF  MILESTONES 
II  AND  III 

Normally,  the  Milestone  II  review  will 
occur  at  the  point  where  a  program 
moves  from  the  Demonstration  and 
Validation  Phase  into  the  Full  Scale  De¬ 
velopment  Phase.  However,  in  certain 
cases,  it  may  be  desirable  to  delay  the 
Milestone  II  Review  until  additional  de¬ 
velopment  effort  has  been  accomplished, 
or  the  review  may  be  divided  into  two 
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reviews,  IIA  and  IIB.  The  delay  or  dual 
review  may  be  made  to  ensure  that  a 
better  definition  of  system  performance, 
IOC  threat,  cost,  schedule,  productivity, 
industrial  base  responsiveness,  pre¬ 
planned  product  improvement  (P3I), 
supportability,  and  testing  are  accom¬ 
plished.  Accordingly,  the  refinement  of 
the  data  facilitates  the  reduction  of  risk 
and  uncertainty  before  the  commitment 
of  substantial  resources  toward  full-scale 
development  is  made. 

The  Milestone  III  review  may  be  divided 
into  two  reviews,  IIIA  and  IIIB.  The 
two  reviews  ensure  that  in-depth  con¬ 
sideration  is  first  given  to  the  produc¬ 
tion  aspects  such  as  special  tooling,  long 
lead  time  items,  and  pilot  assembly,  and 
secondly,  that  an  effective  rate  of  pro¬ 
duction  is  established.  In  addition,  an 
OT&E  should  be  successfully  conducted 
on  a  production-representative  system  to 
verify  the  system’s  operational  effec¬ 
tiveness  and  suitability  and  ensure  that 
it  meets  required  operational  thresholds 
when  proceeding  from  Milestone  IIIA  to 
IIIB. 

5.0  SPECIALIZED  MANAGEMENT 

A  small  number  of  high-priority  pro¬ 
grams  are  designated  for  Specialized 
Management.  Such  programs  involve  a 
limited  number  of  systems  that  require  a 
rapid  response  to  operational  changes 
throughout  the  system’s  life.  Specialized 
management  includes  abbreviated  re¬ 
porting,  coordination,  review  and  budget 
procedures;  waivers  to  Federal  Acquisi¬ 
tion  Regulation  (FAR),  a  range  of  en¬ 
hanced  security  procedures  authorized 
by  DoD  5200. 1R,  including  "Special 
Access  Required"  and  increased  reliance 
on  contractor  support.  With  these  devi¬ 
ations,  Specialized  Management  must  be 
justified  and  wisely  applied.  A  decision 
to  authorize  a  Specialized  Management 
program  will  consider  the  following 
factors: 


a.  Urgency  of  operational  mission. 

b.  Urgency  of  the  development, 
implementation  and  support  necessary  to 
meet  requirements. 

c.  Security. 

d.  Quantity  required. 

e.  Operational  life  of  the  program. 

f.  Contractor  versus  service  sup¬ 
port. 

g.  Applicability  of  military  speci¬ 
fications  to  technical  data,  handbook, 
hardware  and  software. 

h.  Estimated  cost-effectiveness  of 
Specialized  Management  versus  normal 
acquisition  and  support  procedures. 

6.0  SERVICE  PROGRAM  REVIEWS 

Acquisition  program  reviews  by  the  lead 
and  participating  services  have  impacts 
on  joint  programs.  Perhaps  one  of  the 
most  difficult  and  complex  tasks  of  the 
program  manager  is  to  gain  timely  con¬ 
currence  from  the  participating  services 
-  particularly  at  the  headquarters  and 
secretariat  levels.  If  a  major  commit¬ 
ment  is  to  be  expected  from  the  partici¬ 
pating  service  in  a  timely  manner,  a 
viable  interservice  review  and  coordina¬ 
tion  process  must  first  exist.  More  im¬ 
portantly,  the  participating  services  must 
be  made  "participants"  in  the  decision 
process  if  jointness  is  to  be  genuinely 
achieved.  As  a  way  of  expediting  the 
review  process,  the  lead  service  may 
choose  to  conduct  reviews  in  series  or  in 
parallel  with  the  participating  services. 
That  is,  the  lead  service  may  serially 
brief  or  review  program  milestones  in- 
house  to  a  certain  management  level, 
gain  approval,  then  brief  up  the  partici¬ 
pating  service  chain  of  command  to  a 
comparable  level,  include  other  service 
comments  and  continue  to  the  next 
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level.  The  parallel  review  approach 
simply  provides  the  data  to  the  partici¬ 
pating  service  reviewers  in  parallel  prior 
to  lead  service  approval,  incorporates 
comments  as  received  and  seeks  con¬ 
current  approval  from  both  review 
chains  in  order  to  continue  to  the  next 
management  level.  Either  method  can 
be  extremely  time  consuming  if  there 
are  issues  that  cannot  be  readily  re¬ 
solved.  An  approach  proposed  and  ini¬ 
tiated  by  the  INEWS  joint  program  (Air 
Force  lead)  to  promote  involvement  of 
the  participating  service,  was  to  develop 
a  Memorandum  of  Agreement  (MOA) 
that  required  all  AFSARC  decision 
milestone  reviews  to  be  co-chaired  by 
an  appropriate  Navy  counterpart  up  to 
and  through  the  SECNAV/SECAF  lev¬ 
els.  Furthermore,  the  Navy  co-chairman 
was  to  cast  an  equal  vote  in  the  final 
decision.  An  appreciation  of  the  various 
reviews  conducted  by  each  of  the  ser¬ 
vices  is  essential  to  effective  joint  pro¬ 
gram  coordination.  Accordingly,  Tables 
5-1  through  5-4  present  a  summariza¬ 
tion  of  categories,  review  processes,  and 
authority  levels  employed  by  the  ser¬ 
vices  for  all  acquisition  programs. 

7.0  PREPARATION  FOR  THE  DAB 

Preparation  for  the  DAB  requires 
months  of  dedicated  effort  and  consid¬ 
erable  interaction  between  the  joint  pro¬ 
gram  office,  the  participating  services 
and  OSD,  particularly  during  the  three 
months  prior  to  the  DAB.  The  program 
manager  must  prepare  documentation 
and  brief  OSD  staff  personnel,  who 
critically  analyze  the  data  and  provide 
feedback  that  improves  the  potential  for 
a  successful  DAB  review.  A  tentative 
schedule  of  events  is  presented  in  Table 
5-5  P 

8.0  PROGRAM  ASSISTANCE  AND 
SUPPORT 

The  Joint  Program  Manager  has  more 
assistance  available  than  does  the  single¬ 


service  program  manager.  Participating 
service  staffs  and  OSD  not  only  request 
information,  but  also  are  valuable 
sources  of  information.  A  free  flow  of 
information  will  be  mutually  supportive, 
and  the  following  offices  are  likely  par¬ 
ticipants  in  any  such  exchange. 

Air  Force:  The  appropriate  Program 
Element  Monitor  (PEM)  in  the  Office  of 
the  Deputy  Chief  of  Staff,  Research 
Development  and  Acquisition  (AF/RD) 
or  Deputy  Chief  of  Staff,  Logistics  and 
Engineering  (AF/LE). 

Army:  The  appropriate  Department 

of  the  Army  System  Coordinator 
(DASC)  in  the  Office  of  Assistant  Sec¬ 
retary  of  the  Army  for  Research,  Devel¬ 
opment  and  Acquisition  ASA(RDA). 

Navy:  The  appropriate  Deputy  Chief  of 
Naval  Operations  (DCNO)  or  Director 
who  is  the  program  sponsor  or  Director, 
Major  Staff  Office  (DMSO),  who  is  the 


program  sponsor: 

• 

OP-02 

Submarine  Warfare 

• 

OP-03 

Surface  Warfare 

• 

OP-05 

Air  Warfare 

• 

OP-094 

Command  and  Control 

• 

OP-095 

Naval  Warfare 

« 

OP-09B 

Research,  Development 

and  Acquisition 

Marine  Corps:  The  appropriate  Devel¬ 
opment  Program  Officer  (DPO)  in  the 
Office  of  the  Deputy  Chief  of  Staff  for 
Research,  Development,  and  Studies 
(MC-RD). 

Department  of  Defense:  The  appropri¬ 
ate  action  officer  in  the  Office  of  the 
Under  Secretary  of  Defense  (Acqui¬ 
sition)  USD(A). 
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TABLE  5-1  AIR  FORCE  PROGRAM  REVIEW  BY  ACQUISITION  CATEGORY 


TYPE  OF 
ACQUISITION 

-  i 

1 

PRIMARY  CRITERIA 

DQD-designated 

Major  Program 

SECDEF-designated. 

Joint  Acquisition.  S200M 
FY80  RDT&E  or  B1BFY80 
procurement  costs. 

Air  Force-designated 
Major  Program 

SEC  Air  Force-designated 

1 

Non-Major  Program 

None  of  the  above 

LEVEL  OF 
APPROVAL 


SECDEF 


TYPE  OF 
REVIEW 


OAR 

AFSARC 


DECISION 

RECORDING 

DOCUMENT 


See  NOTE 
below. 


NOTE:  In  addition  to  the  program  milsttons  isvisws  for  OAB/AFSARC  low  I  program!,  and  aotaly  for  program!  whoto  iniaraat  or  priority 
la  inaufficiant  to  warrant  DAB/ AFSARC  attention,  the  Air  Farce  employ!  periodic  (vice  program  milaetone)  review!,  at  which  the  PM/5PO 
or  the  AFSC  Syatema  Officer  preaenta  the  atetui  of  program!  aa  followa: 


-  Htgheit  Level: 

-  AFSC  Level: 

-  Product  Dlviaion  Level 


SECAF  Program  Review  (SPR) 

Program  Ataeaamant  Haview  (PAR|  by  Air  Staff 

Command  Ataeaamant  Raviaw  (CAR) 

Managemam  Ataeaamant  Review  (MAR) 

(generally  ieu  then  S2M  to  achieve  program  objectivca 


In  ganaral.  SPR/PARa.  CARa,  and  MARa  era  held  quarterly,  with  monthly  update!  to  the  SPR/PAR.  CAR.  MAH  document  The  level  et 
which  a  program  will  be  reviewed  la  more  dlacnationary  than  coat-influenced. 


TABLE  5-2  ARMY  PROGRAM  REVIEW  BY  ACQUISITION  CATEGORY 


TYPE  OF 
ACQUISITION 

PRIMARY  CRITERIA 

LEVEL  OF 
APPROVAL 

TYPE  OF 
REVIEW 

DECISION 

RECORDING 

DOCUMENT 

DOD  Major 
(PEO) 

Progrsm  of  significant 
interest,  importance,  or 
impacLJoint  Acquisition. 
Threshold  B200M  FY80 
RDT&E  or  *1  B  FY80 
procurement  costs. 

SECDEF 

DAB 

ASARC 

SDDM 

SADM 

Designated 

Acquisition  Program 
(DAP)  (PEO) 

As  directed  by  ASARC 
Chairman  but  not  DOD- 
desigrtated  major 
progiam. 

Army 

Acquisition 

Executive 

(AAE) 

ASARC 

SADM 

IPR 

(PEO) 

None  of  the  above 

PF.O 

iPR 

SADM 

IPR 

(Non-PEO) 

None  of  the  above 

AMC  System 
MSC 

IPR 

SADM 

IPR  —  In-Process  Review 

SDDM  -  Secretary  of  Defense  Decision  Memorandum 
SADM  -  System  Acquisition  Decision  Memorandum 
MSC  -  Major  Subordinate  Command 
PEO  -  Program  Executive  Officer  ^ 

i 


TABLE  5-3  NAVY  PROGRAM  REVIEW  BY  ACQUISITION  CATEGORY 


ACAT  1 

ACAT  II 

ACAT  III 

ACAT  IV(M/T) 

Program  Dacinon 
Authority 

SECDEF 

SECNAV 

DASN 

SYSCOM  CDR  (PEO) 

Oaoaion  Forum 

DAB 

NPDM  11 

NPDM  III 

NPDM  IV 

ACAT  Cntaria 

Joint  Acquisition 
(2Q0M  FY  80  RAO  or 
*1 B  FY  BO  Ffocuramanl 
or  Both 

•  100M  FY  80  R&D  or 
*600M  FY  80  Procuramant 
or  Spacial  SECNAV  Intarait 

Affacta  Military 
Charactariaitca  nr 
bnaracu  Wnh  Enamy 

All  Othai  Programs 
(IV  T  Raquirai  COTF 
Involvamant) 

Documantation 

Aagunad 

JMSNS  Program  Initiation 
SCP  Milaatooa  i 
DCP/lPSMi(a>ionas  11 
*  til  and  TEMP 

OH  Program  Initiation 
NOCPand  TFMF 

OR  and  TEMP 

OR  and  TEMP 

MiUotona  Raviaw 
Program  Initiation 
•  Mtlaatona  0 

POM/PDM 

POM 

POM 

POM 

•  Mtlaatona  1 

bECDEF  (3DDM) 

SECNAV  (SNDM) 

POM 

POM 

•  Mtlaatona  II 

fckCDEF  (SUOMI 

SECNAV  (SNDM) 

DASN 

PEO  Dacia! on 
Marnortndum 

•  Milaatona  III 

SECOEF  cr  Mayba 
DolagatXl  io  SECNAV 

SECNAV  (SNDM) 

DASN 

PEO-Oaciaion 

Mamuranduni 

TABLE  5-4  MARINE  CORPS  PROGRAM  REVIEW  BY  ACQUISITION  CATEGORY 


ACAT  1 

ACAT  II 

AC  A  t  III 

ACAT  IV  (M/T) 

Program  Daemon 
Authority 

SECOEF 

SECNAV 

DASN 

DC/S  (RDIiS)(PE0| 
or  DC/S  (IBIHPEO) 

Dooaion  Forum 

DAB 

MCPDM  II 

MCPDM  Ili 

MCPDM  IV 

ACAT  Cntaria 

Joint  Acquitttkon 
9200MFY80  RADoi 
*18  FY  80  Procuramatit 
or  Both 

•  GOM  FY  80  n&D  or 
I2G0M  FY  SO  Production 

06M  FY  00  RAD  or 
82GM  FY  80  Production 

Ali  Othar  Program* 

(IV  T  Raquiraa  MCOTEA 
Involvamant) 

Documantatlon 

Raquirod 

JM&NS -Program  initiation 
SC'r  •  Mil«**or*a  1 
OCP/iPS-Milaaionaatl 

A  Ili  ardTEMP 

OR-Pfcgram  Initiation 
ROC  and  TEMP 

ROC  and  TEMP 

ROC  and  TEmk 

Mtlaatona  Raviaw 
Program  Initiation 
•  Milattona  0 

POM/PDM 

POM 

POM 

POM 

•  Mtlaatona  1 

SECOEF  (SDDM) 

SECNAV  (SNDM) 

POM 

POM 

#  Mtlaatona  II 

SECOEF  (SDDM) 

SECNAV  (SNDM) 

DASN 

PEODaciaton 

Mamorandum 

•  Mtlaatona  III 

SECDEF  or  Mayba 
Dalagatad  to  SECNAV 

SECNAV  (SNDM) 

DASN 

PEO  Daciaton 
Mamorandum 

TABLE  5-5  TENTATIVE  PREPARATION  SCHEDULE  FOR  DAB  7 


Tasks 

Time  Prior 
to  DAB 

1 )  Milestone  planning  meetii  g  (optional).  As  determined  by  DAE 
or  the  joint  program  manager,  an  informal  planning  meeting 
held  to  identify  program  issues  before  submission  of  applicable 
draft  documentation  for  the  specified  milestone  review. 

3  to  6  months 

2)  Draff  program  documentation.  The  SCP  or  DCP/IPS  is  sub¬ 
mitted  to  the  OSD  action  officer  who  distributes  it  to  the  DAB 
members. 

3  months 

3)  DAE  comments  on  draft  documentation.  The  DAE  transmits 
formal  comments  to  the  joint  program  manager  and  every  effort 

3s  made  to  resolve  any  issues  prior  to  the  DAB  review. 

2  months 

4)  Final  documentation  update  is  submitted  to  the  DAB. 

3  weeks 

6)  Joint  program  staff  briefings  to  OSD.  The  advisors  then  brief 
their  findings  on  the  program  to  other  involved  OSD  personnel. 

3  weeks 

6)  DAB  pre-briefings.  The  OSD  staff  brief  the  DAB  members  on 
the  joint  system. 

2  weeks 

7)  OSD  staff  reports  sent  to  DAB  members. 

6  workdays 

8)  DAB  Review 

DAB  executive  session* 

0 

*  The  executive  session  expedites  the  evaluation  of  the  data  presented  to  the  DAB  and 
facilitates  the  preparation  and  issue  of  the  SDDM,  approximately  three  weeks  after  the 
DAB  review. 


DASCs,  program  sponsors,  DPOs,  PEMs 
and  action  officers  may  have  several 
projects  to  monitor,  or  only  one.  Army 
DASCs  and  Air  Force  PEMs  are  likely 
to  have  a  single  program.  The  Navy 
program  sponsor,  the  Marine  Corps 
(DPO),  and  the  USD(A)  action  officers 
are  likely  to  monitor  many  projects  in 
their  specific  warfare  disciplines.  Con¬ 
sequently,  more  initiative  is  required  to 
coordinate  with  these  Navy,  Marine 
Corps  and  USD(A)  points  of  contact. 

The  Joint  Program  Manager’s  relation¬ 
ships  with  these  monitors  should  be  as 
open  as  possible.  They  are  often  called 
upon  to  make  planning,  programming  or 
resource  allocation  recomendations  to 
service  secretariat  or  OSD  decision¬ 
makers.  While  the  program  manager  is 
concerned  about  trade-offs  among  the 
competing  demands  of  system  perfor¬ 
mance,  cost,  and  schedule,  they  are 
answering  queries  and  providing  infor¬ 
mation  and  recommendations  that  can 
enhance  or  undo  the  program  acquisition 
strategy.  Prompt  responses  to  their  re¬ 
quests  for  information  will  make  suc¬ 
cessful  accomplishment  of  the  program 
reviews  much  easier. 

Furthermore,  the  Pentagon  monitors  as¬ 
sociated  with  a  developing  joint  program 
are  likely  to  be  much  more  knowledge¬ 
able  about  the  various  service-OSD  in¬ 
terfaces  than  the  program  manager. 
Many  of  them  will  have  processed 
MENS,  DCPs,  and  SDDMS  previously, 
and  have  experience  with  the  incumbent 
principal  decision-makers.  They  will  be 
the  sources  of  the  understanding  of  the 
details  behind  the  generalized  DOD  ac¬ 
quisition  documents  and  of  the  areas 
where  promulgated  directives  are  not 
totally  definitive.  Some  have  detailed 
internal  staff  check  lists  and  guides  for 
use  in  the  review  process  that  could  be 
of  assistance.  The  new  joint  program 
manager  can  receive  the  benefit  of  this 
assistance  and  support  through  a  coop¬ 


erative  relationship  with  these  experi¬ 
enced  professionals. 

9.0  SUMMARY 

•  The  objectives  of  program  reviews 
are  to  determine  that  an  acquisition  pro¬ 
gram  is  viable,  valid  and  cost  effective 
as  it  progresses  through  the  acquisition 
process. 

•  Program  reviews  are  established  at 
specific  milestones  throughout  an  acqui¬ 
sition  to  ensure  that  all  areas  of  risk  and 
uncertainty  of  a  program  are  carefully 
considered  before  proceeding  to  the  next 
acquisition  phase. 

•  Risk  is  defined  as  the  condition  of 
having  outcomes  with  known  probabili¬ 
ties  of  occurrence,  not  certainty  of  oc¬ 
currence. 

•  Uncertainty  is  defined  as  the  con¬ 
dition  of  having  outcomes  with  un¬ 
known  probabilities  of  occurrence. 

•  Reviews  consider  one  system  at  a 
time. 

•  Milestone  0,  the  Mission  Need 
Determination,  is  accomplished  in  the 
PPBS  process,  utilizing  the  JMSNS  sub¬ 
mitted  with  the  POM  and  the  DAB  re¬ 
view  for  most  major  systems  before  the 
system  can  commence  the  Concept  Ex¬ 
ploration  Phase. 

•  Milestone  I,  the  Requirement  Vali¬ 
dation,  is  accomplished  through  the 

t/nw  tgvicW,  n  ov  J  miiu  i.l>Ivii  a  it 

submitted  for  review  before  the  program 
can  move  into  the  Demonstration/ 
Validation  Phase. 

•  Milestone  II,  the  Program  Go 
Ahead,  is  also  accomplished  through  the 
DAB  review.  A  DCP,  IPS,  TEMP  and 
LRIP  Report  are  submitted  for  review 
before  the  program  can  proceed  to  the 
Full  Scale  Development  (FSD)  Phase. 
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The  Milestone  II  review  may  he  divided 
into  two  reviews,  IIA  and  IIB  or  delayed 
to  facilitate  the  development  of  data  that 
will  reduce  the  risk  and  uncertainty 
prior  to  the  commitment  of  substantia! 
resources  for  the  Full  Scale  Development 
(FSD)  Phase. 

•  Milestone  III,  Production  Ratifica¬ 
tion,  could  be  accomplished  by  a  service 
review  or  by  the  DAB  if  determined 
necessary.  Updated  and  expanded  ver¬ 
sions  of  the  Milestone  II  documents  are 
submitted  for  the  Milestone  III  review. 
The  Milestone  III  review  may  also  be 
divided  into  two  reviews,  IIIA  and  1IIB, 
if  necessary,  to  ensure  that  adequate 
consideration  is  given  to  production  as¬ 
pects  of  the  acquisition  at  IIIA  and  that 
an  effective  rate  of  production  is  estab¬ 
lished  at  IIIB. 

«  Approval  of  Milestone  0  through  II 
reviews  are  accomplished  by  SECDEF 
Decision  Memorandums  (SDDMs).  Ap¬ 
proval  of  the  Milestone  III  review  is 
provided  through  a  memorandum  from 
the  Commander,  Lead  Service,  or  by  an 
SDDM  as  appropriate. 

•  A  small  number  of  high-priority 
programs,  that  involve  a  limited  number 
of  systems  which  require  a  rapid  re¬ 
sponse  to  operational  changes  throughout 
a  system’s  life,  may  be  designated  for 
Specialized  Management  if  adequately 
justified. 

•  Acquisition  program  reviews  vary 
by  service.  However,  an  appreciation  of 
ine  reviews  is  essential  to  effective  joint 
program  coordination. 

•  A  tentative  schedule  of  three  to  six 
months  has  been  developed  to  assist  the 
Joint  Program  Manager  in  preparing  for 
a  DAB  review. 

•  Participating  service  staffs  and  OSD 
can  be  vital  sources  of  information. 


RKFKRfiNCESLANP  FOOTNOTESl 

\J  'Risk  Assessment  Technique*  -  A  Handbook 
for  Program  Management  Personnel,"  DSMC,  First 
Edition,  July  1983,  pp.  B-S  and  B-6. 

%j  DoD  Dlructiv*  6000.1,  "Major  Sy»t«m  Acqui¬ 
sition,"  12  March  1986. 

4/  DoD  Instruction  6000.2,  "Major  System  Ac¬ 
quisition  Procedural,"  12  March  1986. 

4/  Figure  S-l  is  bused  on  DSMC  churt  SE-T 
1001  from  "Program  Manager,"  DSMC,  Jan-Feb. 
1983  Issus  und  ruvissd  to  reflect  DoD  Directive 
S000.1  und  DoD  Instruction  0000.2  of  12  Murch 
1986,  und  DoD  Directive  SlS4.lt,  "Under  Secretary 
of  Dslsnts,"  10  February  1987. 

£/  Thu  authority  for  the  Defense  Acquisition 
Board  (DAD)  is  DoD  Directive  SI34.1,  "Undsr  Sec¬ 
retary  of  Detunes,"  10  February  1937. 

gy  DoD  Directive  6000, S,  "Test  and  Evaluation," 
12  March  1936. 

u  Table  6-6  is  based  on  Table  1  of  the  "Program 
Manager's  Notebook,"  Fact  Sheet  No.  1-6. 
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CHAPTER  6 

ORGANIZATION  AND  STAFFING 


1.0  SYNOPSIS 

This  chapter  discusses  the  variety  of  or¬ 
ganizational  structures  that  exist  in  the 
joint  acquisition  program  environment, 
and  major  aspects  of  staffing,  particu¬ 
larly  an  integrated  office.  Section  2.0 
discusses  the  rationale  of  creating  a  va¬ 
riety  of  joint  program  offices  to  meet 
the  needs  of  a  multiservice  acquisition. 
In  section  3.0,  the  establishment  of  joint 
service  program  offices  is  discussed. 
The  various  organizational  structures  of 
joint  service  programs  are  presented  in 
section  4.0.  Next,  sections  5.0  through 
8.0  provide  insight  into  the  personnel 
aspects  of  joint  program  offices.  Fi¬ 
nally,  section  9.0  presents  a  summary  of 
the  significant  points  of  the  chapter. 

2.0  JOINT  PROGRAM  OFFICE 
VARIATIONS  RATIONALE 

The  joint  program  structure  depends  on 
the  size  and  goals  of  the  program,  the 
phase  of  the  program  in  the  acquisition 
process,  the  agreed-to  relationship 
among  the  participating  services,  the  ac¬ 
quisition  strategy  for  the  program,  and 
the  role  of  OSD,  JCS  or  the  JLC  in  tho 
program.  There  is  a  wide  variety  of 
joint  program  organizations  as  discussed 
in  section  3.0  of  Chapter  1.  (Also  see 
Table  1-1.)  There  is  no  standard  for 
joint  program  office  organizations. 
Each  joint  program  manager  must  tailor 
the  PM’s  organization  to  the  mission, 
functional  relationships  with  participat¬ 
ing  services  and  to  the  extent  of  the 
responsibilities  of  the  joint  program  of¬ 
fice.  In  addition,  in  the  course  of  an 
acquisition  program,  management  or  or¬ 
ganizational  approaches  may  need  to 
evolve  from  one  category  to  another 
over  the  years  due  to  a  number  of  cir¬ 
cumstances,  such  as  increased  top-level 
interest,  revised  mission  priorities, 
funding  allocation  changes,  etc. 


Joint  program  offices  normally  require 
more  personnel  than  typical  single-ser¬ 
vice  programs  due  to  the  greater  need 
for  coordination  and  the  need  for  being 
aware  of  participating  services’  efforts. 
Joint  service  program  efforts  also  re¬ 
quire  more  diverse  skills  and  specialties 
resident  in  the  joint  program  office  to 
handle  the  increased  complexities  of  a 
joint  acquisition.  Grade  structure  of  the 
joint  program  office  tends  to  be  higher 
because  of  increased  responsibilities,  and 
because  the  tasks  require  considerable 
knowledge  of  how  each  service  operates. 
This  is  especially  true  in  the  logistics 
areas,  as  personnel  tend  to  be  specialized 
and  many  problems  in  inter-service  lo¬ 
gistics  are  manpower  intensive.  Current 
formal  and  service  training  is  focused 
toward  the  parent  service  and  therefore 
there  is  a  considerable  learning  period 
of  six  to  eight  months,  before  an  officer 
or  civilian,  knowledgeable  in  one  ser¬ 
vice,  can  be  effective  in  representing 
another  service  or  joint  services.  In  ad¬ 
dition,  the  increased  business  manage¬ 
ment  requirements  of  a  joint  program 
necessitate  additional  staff  to  maintain 
larger  volumes  of  records,  prepare  sep¬ 
arate  briefings  and  to  conduct  additional 
budget  exercises  required  by  the  partici¬ 
pating  services. 

3.0  ESTABLISHMENT  OF  JOINT 
SERVICE  PROGRAM  OFFICES 

As  stated  in  section  3.0  of  Chapter  2, 
joint  program  offices  can  and  should  be 
established  through  mutual  agreements 
between  two  or  more  services  whenever 
a  mutual  or  similar  need  or  requirements 
exists.  Normally,  the  office,  be  it  the 
Defense  Acquisition  Executive  (DAE), 
JCS,  JLC  or  one  of  the  services,  will 
initiate  the  joint  program  in  the  form  of 
a  memorandum  designating  a  lead  ser¬ 
vice  and  directing  that  service  to  charter 
a  joint  program.  (See  section  5.0  of 
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Chapter  2  for  a  discussion  of  charters.) 
Normally,  the  lead  service  will  provide 
the  program  manager,  however,  there 
have  been  exceptions  where  a  partici¬ 
pating  service  was  designated  to  provide 
the  PM. 

Joint  service  programs  involve  continu¬ 
ous,  dynamic  and  complex  processes 
with  substantial  areas  for  dispute.  DoD 
Directive  5000.1  and  DoD  Instruction 
5000.2  of  12  March  1986,  and  the  joint 
regulation,  AFSC/AFLC  800-2,  AMC 
R  7-59,  NAVMATINST  5000. 10A  pro¬ 
vide  only  a  basic  framework  on  which 
to  resolve  interservice  issues.^^*^ 
Usually,  resolution  is  accomplished 
through  compromise  and  negotiation 
resulting  in  one  or  more  Memorandums 
of  Agreement  (MOA)  between  the  ser¬ 
vices. 

4.0  JOINT  SERVICE  PROGRAM 
STRUCTURES 

Joint  service  programs  range  from  a 
loose  structured  organization  to  an  inte¬ 
grated  structured  organization.  Regard¬ 
less  of  the  initial  structure,  a  program 
office  assumes  the  organizational  struc¬ 
ture  should  be  reviewed  periodically  to 
ensure  that  the  most  efficient  and  ef¬ 
fective  organization  is  employed  to  meet 
the  needs  of  the  program  as  it  progresses 
through  the  acquisition  process.^ 

Normal  Joint  Service  Program  Offices. 
Many  joint  programs,  especially  small 
programs,  are  joint  only  because  their 
goals  are  to  satisfy  joint  requirements. 
For  the  most  part,  these  programs  are 
structured  and  managed  as  they  wouid 
be  if  they  were  single-service  programs. 
The  participating  service  may  assign  a 
liaison  officer  or  representative  to  the 
program  office,  or  it  may  simply  moni¬ 
tor  the  program.  Normally,  the  interests 
of  the  lead  service  will  dominate  the 
program. 


Jointly  Staffed  Program  Offices.  The 
jointly  staffed  program  office  is  the 
structure  most  preferred  by  the  services. 
In  these  organizations,  the  lead  service 
usually  provides  the  program  manager, 
most  of  the  program  management  staff, 
and  administrative  support.  The  par¬ 
ticipating  services  each  contribute  a 
deputy  program  manager  and  other  mil¬ 
itary  officers  to  the  program  manage¬ 
ment  staff.  Though  not  explicit  about 
program  structure,  the  Joint  Logistic 
Commanders*  Memorandum  of  Agree¬ 
ment  (MOA)  on  "Management  of  Multi- 
Service  Programs/Projects"  (see  Ap¬ 
pendix  A)  assumes  the  creation  of  a 
jointly  staffed  program  office,  and  most 
programs  structured  that  way  follow  the 
guidelines  of  the  MOA. 

Multiple  Program  Offices.  A  number  of 
joint  programs  are,  in  fact,  multiple 
programs  whose  activities  are  coordi¬ 
nated.  The  degree  and  method  of  coor¬ 
dination  vary  from  program  to  program, 
as  does  the  principal  source  of  program 
direction.  Frequently,  the  OSD  plays 
some  direct  role  in  the  program’s  execu¬ 
tion.  Many  joint  programs  in  this  cate¬ 
gory  have  unique  management  struc¬ 
tures.  Four  examples  of  these  structures 
are  depicted  in  Figure  6-1.  The  struc¬ 
ture  shown  in  structure  A  of  Figure  6-1 
can  be  considered  a  joint  program  con¬ 
federation.  Each  service  manages  its 
own  program  but  exchanges  information, 
regularly  with  the  other  services.  OSD 
sometimes  orchestrates  the  efforts,  di¬ 
viding  responsibilities  among  the  ser¬ 
vices  to  eliminate  duplication  or  to  en¬ 
sure  that  alternatives  are  explored.  OSD 
direction  and  inter-service  interactions 
are  minimal. 

The  opposite  is  true  of  the  joint  pro¬ 
gram  structure  depicted  in  structure  B  in 
Figure  6-1.  In  it,  a  jointly  staffed  OSD 
program  office  is  created.  Subordinate 
project  offices  are  staffed  and  adminis¬ 
tratively  supported  by  the  services. 
Program  direction  is  provided  by  OSD. 
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Figure  6-1  Structures  of  Joint  Programs  Having 
Multiple  Program  Offices 
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Structure  C  of  Figure  6-1  shows  a  pro¬ 
gram  structure  that  is  similar  to  that  in 
structure  B.  The  difference  is  that  in¬ 
stead  of  creating  an  OSD  program  of¬ 
fice,  one  of  the  services  is  tasked  to 
provide  overall  program  management. 
Individual  programs  are  managed  by  the 
services,  Central  control  is  less  exten¬ 
sive  than  that  exercised  by  an  OSD  pro¬ 
gram  office,  concentrating  primarily  on 
requirements,  funding,  and  configura¬ 
tion. 

Structure  D  depicts  another  variation  of 
the  structure  B  of  Figure  6-1.  Direction 
to  the  joint  program  office  is  provided 
by  an  executive  committee  comprised  of 
senior  representatives  from  each  of  the 
services  participating  in  the  program,  as 
well  as  from  OSD.  Such  an  arrangement 
tends  to  moderate  OSD  control  of  the 
program,  yet  still  provide  strong,  central 
program  direction. 

5.0  THE  PROGRAM  MANAGER 

The  lead  service  usually  appoints  the 
program  manager,  who  should  bo  of  a 
rank  commensurate  with  the  size  and 
importance  of  the  program.^  The  PM 
will  be  the  primary  advocate  of  the  pro¬ 
gram  and  must  manage  the  program  to¬ 
wards  the  successful  conclusion  of  the 
system  acquisition. 

6.0  PROGRAM  OFFICE  STAFFING 

There  are  two  basic  alternatives  for  pro¬ 
gram  office  organization.  One  is  to  in¬ 
clude  all  functional  specialists  needed 
for  program  execution  in  the  program 
office  staff,  essentially  establishing  a 
self-contained  organization.  The  other 
is  to  restrict  the  program  management 
staff  to  a  cadre  of  managers  who  draw 
functional  support  from  the  participat¬ 
ing  services,  -and  function  as  a  matrix 
organization.  Most  program  manage¬ 
ment  organizations  are  neither  com¬ 
pletely  self-contained  nor  completely 
matrix,  but  a  mixture  of  the  two, 


Large,  high-priority  programs,  especially 
in  the  Air  Force  and  Navy,  tend  more 
toward  the  self-contained  program  of¬ 
fice  organization,  depending  less  on 
small  outside  matrix  resources;  low-pri¬ 
ority  programs  tend  more  toward  the 
matrix  type.  The  joint  staff  manning 
effort  should  include  a  configuration  of 
agreed-to  position  types  and  numbers, 
their  configuration  and  estimated  dura¬ 
tion  of  service.  The  personnel  require¬ 
ments  should  be  specified  as  military  or 
civilian  and  the  service  providing  the 
resource.  Sufficient  time  must  be  al¬ 
lowed  in  filling  civilian  requirements. 

Joint  programs  normally  follow  the  or¬ 
ganization  practice  of  the  lead  service. 
However,  in  a  jointly  staffed  program 
office,  it  is  normally  desirable  to  include 
on  the  program  management  staff  as 
much  functional  expertise  as  practicable. 
Supporting  a  joint  program  that  lias  the 
active  participation  of  two  or  more  ser¬ 
vices  is  an  extraordinary  task.  It  is  time 
consuming,  Many  of  the  services'  nor¬ 
mal  procedures  must  be  modified  or 
abandoned  in  favor  of  procedures  better 
suited  to  the  program’s  needs.  A  func¬ 
tional  specialist  who  is  assigned  full¬ 
time  to  the  program  management  staff  is 
more  likely  to  share  fully  in  the  spirit 
and  objectives  of  vhe  program  and  to 
cling  less  fervently  to  service-peculiar 
procedures  than  is  one  who  is  working 
part-time  for  the  program. 

A  complicating  factor  ip  the  organiza¬ 
tion  of  a  jointly  staffed  program  office 
is  the  assignment  of  responsibilities  to 
personnel  from  the  participating  ser¬ 
vices.  The  fact  that  the  program  office 
is  jointly  staffed  is  evidence  of  the  par¬ 
ticipating  services'  desires  to  influence 
the  program.  However,  it  should  be 
clear  from  the  organization  of  the  pro¬ 
gram  office,  as  well  as  stated  in  the 
charter,  that  the  participating  services’ 
representatives  share  responsibility  for 
success  of  the  joint  program.  They  are 
not  merely  representing  their  services’ 
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interests.  To  accomplish  this,  the  joint 
program  manager  should  organize  the 
office  staff  and  allocate  key  positions 
among  the  services  such  that  a  balance 
of  responsibility,  authority,  and  influ¬ 
ence  is  maintained.  Echelon  parity 
among  engineering,  logistics,  and  pro¬ 
curement  positions  should  be  maintained 
as  well.  The  senior  representatives  from 
the  participating  services  must  be  in  the 
chain-of -command,  directly  subordinate 
to  the  program  manager.  Sometimes  this 
may  require  creating  one  or  more  posi¬ 
tions  for  principal  deputy  program 
managers.  Creating  extra  positions  is 
preferable  to  rotating  one  position 
among  the  participating  services  or  to 
slighting  the  interests  of  one  by  subor¬ 
dinating  its  representative  to  the  other 
services’. 

7.0  SI  AM  PERSONNEL  SELECTION 

One  of  the  joint  program  manager’s 
major  challenges  is  creating  an  esprit  dc 
corps  within  the  program  office.  Situa¬ 
tions  are  bound  to  arise  in  which  the 
participating  services’  interests  conflict. 
Success  of  the  program  may  then  depend 
on  having  program  management  staff 
personnel  who  are  committed  to  resolv¬ 
ing  the  problem,  rather  than  provoking 
confrontations.  Staff  members  and 
representatives  from  the  participating 
services  can  be  expected  to  protect  their 
services’  interests;  that  may  be  why  they 
are  assigned  to  the  program  office.  Out 
their  attitude  and  approach  must  be 
dedicated  to  success  of  the  program. 

The  joint  program  manager  will  need 
the  same  type  of  personnel  required  'ey 
all  staffs:  knowledgeable,  hard-working, 
efficient,  and  loyal.  More  than  others, 
however,  the  joint  program  manager 
needs  people  who  can  work  well  with 
others  and  who  are  willing  to  explore 
unique  solutions  to  management  prob¬ 
lems.  The  joint  program  staff  must  be 
creative,  flexible,  and  determined. 
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Selection  of  the  deputy  program  man¬ 
agers,  especially  those  from  the  partici¬ 
pating  services,  is  particularly  important 
to  the  joint  program  manager.  The 
Deputy  Joint  Program  Managers 
(DJPMs)  have  dual  responsibilities,  pri¬ 
marily  to  the  parent  service  they  repre¬ 
sent  and  secondarily  to  the  joint  pro¬ 
gram.  DJPMs  are  responsible  for  en¬ 
suring  that  the  system  being  designed, 
developed  or  acquired  will  attain  the 
performance  reliability,  availability  and 
supportability  requirements  needed  by 
the  Service  the  DJPM  represents.  To 
accomplish  such  responsibilities,  the 
DJPMs  as  well  as  the  PM,  must  be 
acute'y  aware  of  the  areas  where  their 
influence  and  authority  are  most  impor¬ 
tant.  In  addition,  both  the  PM  and  the 
DJPMs  must  work  towards  the  ultimate 
success  of  the  joint  program  while  still 
endeavoring  to  achieve  the  requirement 
needs  of  their  respective  services.  Not 
only  must  the  PM  have  confidence  in 
the  abilities  of  the  deputies,  but  the 
deputies  must  also  be  able  to  develop  a 
good  working  relationship  with  the  PM. 
Personality  conflicts,  even  among  people 
who  are  otherwise  competent,  can  un¬ 
dermine  a  joint  program.  Before  ac¬ 
cepting  assignment  of  key  personnel,  the 
program  manager  should  interview  them, 
discuss  program  objectives,  management 
approach,  and  management  philosophy, 
and  be  satisfied  that  each  will  become  a 
part  of  a  good  management  team.  Such 
interviews,  of  course,  would  most  cer¬ 
tainly  .ecessitate  inclusion  of  interview 
parameters  in  the  MOA,  since  it  would 
seem  a  bit  presumptive  to  assume  that 
the  services  would  permit  another  ser¬ 
vice  to  screen  iheir  handpicked  Candi¬ 
date  for  a  joint  program  office  position. 

With  the  passage  of  the  Goldwater- 
Nichols  Department  of  Defense  Reorga¬ 
nization  Act  of  1986,-/  the  esprit  de 
corps  in  joint  program  offices  should 
progressively  improve  as  officers,  with 
joint  specialty  designators,  are  assigned 
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and  have  prior  training  and/or  experi-  can  function  effectively,  particularly 

ence  in  joint  staff  environments.  where  it  involves  other  services. 


8.0  PERSONNEL  EVALUATIONS 

As  a  general  rule,  each  person’s  perfor¬ 
mance  should  be  evaluated  by  his/her 
supervisor.  In  joint  programs,  this  rule 
can  be  followed  for  most  personnel. 
The  common  exception  is  for  military 
officers,  assigned  by  a  participating  ser¬ 
vice  to  a  jointly  staffed  program  office. 
It  is  normally  considered  important  to  an 
officer’s  career  for  his/her  performance 
to  be  evaluated  by  an  officer  of  his/her 
own  service.  Therefore,  in  a  jointly 
staffed  program  office,  the  participating 
services’  senior  representatives  should  be 
responsible  for  evaluating  the  perfor¬ 
mances  of  officers  from  their  services. 

The  program  manager,  however,  should 
always  evaluate  the  performances  of  the 
participating  services’  senior  representa¬ 
tives,  even  if  they  are  evaluated  also  by 
the  participating  services. 

9.0  SUMMARY 

«  There  are  a  wide  variety  of  joint 
program  structures  and  organizations 
depending  on  tlu  size  and  goals  of  the 
program,  interest  of  OSD,  JCS,  or  the 
JLC,  participating  services’  involvement, 
etc. 

•  Each  joint  program  manager  must 
tailor  the  program  office  organization  to 
function  in  the  most  efficient  and  ef¬ 
fective  manner.  There  are  no  standards 
for  joint  program  office  organizations. 


•  One  of  the  major  challenges  for  a 
joint  program  manager  is  to  develop  an 
esprit  de  corps  within  the  program  of¬ 
fice.  The  esprit  de  corps  should  pro¬ 
gressively  improve  as  a  result  of  the 
Goldwater-Nichols  DoD  Reorganization 
Act. 
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•  Joint  program  offices  require  more 
personnel  than  typical  single-service 
program  programs  due  to  the  greater 
need  for  coordination  and  interfaces 
with  the  various  participating  services. 

•  Normally,  a  learning  period  of  six 
to  eight  months  is  required  before  new 
key  personnel  in  a  joint  program  office 
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CHAPTER  7 

FINANCIAL  MANAGEMENT 


1.0  SYNOPSIS 

Financial  Management  (FM)  is  an  ex¬ 
tremely  important  function  and  one 
which  crosses  ail  other  facets  of  the 
program  from  early  requirements  deter¬ 
mination  (as  related  to  initial  afford¬ 
ability  issues)  to  the  final  disestablish¬ 
ment  of  the  Program  Office  or  transfer 
of  accountability  for  a  specific  weapon 
system.  The  Financial  Manager  (or 
Business/Financial  Manager)  v/ill  be  in¬ 
volved  in  a  wide  range  of  resource  is¬ 
sues  including: 

•  Cost  Estimating 

•  Contractor  Performance  Measure¬ 
ment 

•  Design  to  Cost 

•  Budgeting 

•  Funding 

•  Risk  Analysis 

•  Proposal  Evaluation 

•  Life  Cycle  Costing 

•  Financial  Management  Information 
Systems  (FMIS) 

Section  2.0  of  this  chapter  will  deal  with 
the  Joint  Financial  Management  Func¬ 
tion,  Section  3.0  with  cost  estimating, 
Section  4.0  wth  cost  terms,  and  Section 
5.0  with  Financial  Management  Infor¬ 
mation  Systems.  Section  6.0  will  sum¬ 
marize  this  chapter. 

2.0  JOINT  FINANCIAL  MANAGE¬ 
MENT 

Recently,  the  issues  of  cost  reporting 
and  financial  management  have  been 


receiving  increased  emphasis  as  a  result 
of  budgetary  restrictions,  Congressional 
reporting  requirements,  and  the  neces¬ 
sity  for  overall  increased  efficiency  in 
acquisition  management. 

The  baselining  of  selected  major  systems 
has  been  instituted  to  enhance  program 
stability  and  control  cost  growth  of  se¬ 
lected  major  programs.^  Baselines  are 
established  for  development  and  pro¬ 
duction,  and  address  technical  parame¬ 
ters,  milestones  and  schedules,  and  cost 
estimates  and  goals.  K  cost  cap,  which 
is  the  maximum  total  dollar  amount 
(program  acquisition  cost)  which  DoD  is 
willing  to  commit  for  the  capability  be¬ 
ing  acquired,  may  be  considered. 

Selection  and  assignment  of  an  experi¬ 
enced  and  knowledgeable  Financial 
Manager  is  essential  to  establishment  of 
a  sound  financial  base  for  a  Joint  Ser¬ 
vice  Program.  Regardless  of  the  official 
title.  Fiscal  Manager,  Controller,  Finan¬ 
cial  Manager  or  Business  Manager,  the 
financial  management  responsibilities  are 
the  same.  They  are  pervasive,  encom¬ 
passing  planning  and  control  i  r  all  fi¬ 
nancial  matters  relating  to  programming, 
budgeting,  allocating,  committing,  obli¬ 
gating,  expending  and  accounting  of 
funds,  for  salaries,  for  example,  as  well 
as  actual  equipment  or  system  develop¬ 
ment.  The  financial  manager  must  be 
on  board  and  deeply  involved  in  finan¬ 
cial  analysis  and  planning  needed  to  es¬ 
tablish  program  cost  estimates,  and  be 
the  principal  architect  on  preparing  the 
Joint  Program  Funding  Plan.  The 
funding  plan  should  be  keyed  to  the 
work  breakdown  structure  and  master 
schedule  prepared  by  program  analysts 
with  the  assistance  of  cost  analysis  ex¬ 
perts,  and  must  include  a  time-phased 
profile  of  funding  requirements  by  type 
and  source.  The  plan  must  lend  itself  to 
ease  of  breakout  of  funds  by  source, 


particularly  the  "other"  services  planned 
contribution  of  funds,  by  type. 
Selection  and  assignment  of  a  competent 
financial  manager  and  development  of  a 
comprehensive  funding  plan  are  key 
first  steps  in  establishing  a  sound 
business  base  for  the  Joint  Service 
Program.  Accordingly,  the  first  critical 
task  that  must  be  accomplished  by  the 
financial  or  business  manager  is 
development  of  the  funding  plan. 

A  second  critical  task  will  be  to  estab¬ 
lish  procedures  for  controlling  allocated 
funds  which  afford  the  joint  program 
manager  the  utmost  flexibility  in  exe¬ 
cuting  program  requirements  and  which 
are,  at  the  same  time,  responsive  to  the 
financial  management  resonsibilities  and 
priorities  of  the  participating  services. 
All  obligational  authority  for  the  Joint 
Service  Program  should  be  transferred  to 
the  Joint  Program  Office  or  that  office’s 
present  development/logistics  command, 
even  if  some  obligational  authority  is 
returned  to  the  participating  services. 
The  Joint  Program  Office  should  use  the 
financial  management  and  accounting 
procedures  of  the  lead  service. 

Programming  and  budgeting  activities 
also  should  be  centrally  directed  by  the 
Joint  Program  Manager.  Although  the 
programming  and  budgeting  processes  in 
all  the  services  follow  the  same  general 
pattern  and  schedule  established  by  the 
Office  of  the  Secretary  of  Defense 
(OSD),  practices  do  vary  from  service  to 
service.  Moreover,  specific  practices  are 
likely  to  vary  from  year  to  year  within 
any  service.  The  Joint  Program  Man¬ 
ager  or  the  PM's  financial  manager  are 
not  advised  to  attempt  to  become  expert 
in  the  service-to-service  variations. 
Where  possible,  and  certainly  in  the  case 
of  a  large  program  office  staff,  financial 
experts  from  each  of  the  participating 
services  should  be  included.  When 
staffing  authorizations  or  lack  of  avail¬ 
able  personnel  preclude  such  staffing, 
the  financial  manager  must  establish  and 


exercise  close  coordination  with,  and 
obtain  timely  assistance  of  controller  and 
Headquarters  Staff  personnel  in  the  par¬ 
ticipating  services.  Specific  points  of 
contact  must  be  established  and  working 
relationships  cultivated  to  ensure  quick 
and  decisive  responses  to  financial 
management  matters.  Just  as  important 
is  the  matter  of  the  Joint  Program  Of¬ 
fice  keeping  the  participating  services 
informed  (up-to-date)  on  financial  sta¬ 
tus  relating  to  allocation  commitment 
and  obligation  of  funds.  In  any  event, 
the  Financial  Manager  should  ensure 
that  program  and  budget  submissions  are 
compatible  with  the  master  schedule  and 
joint  program  funding  plan;  that  these 
come  together  at  OSD  as  a  joint  funding 
requirement,  and  are  justified  before 
OSD,  OMB  and  Congress  as  a  joint  pro¬ 
gram. 

Joint  Program  Managers  learn  soon  after 
assuming  office  that  certain  individuals 
outside  their  program  office  can  expe¬ 
dite  or  impede  their  progress  and  that 
good  working  relationships  with  such 
individuals  should  be  established  at  the 
outset,  Among  these  people  are  the  ser¬ 
vice  comptrollers,  at  both  headquarters 
and  systems  command  levels.  For  in¬ 
stance,  it  is  often  the  comptroller  of  the 
systems  command  providing  support  to 
the  program  office  (e.g.,  Naval  Sea  Sys¬ 
tems  Command)  who  issues  the  budget 
call  and  the  call  for  the  annual  program 
objective  memorandum  (POM)  to  which 
the  joint  program  manager  must  provide 
inputs. 

Most  program  managers  have  found  it 
advisable  to  have  frequent  contact  with 
the  comptroller  and,  at  all  times,  to  be 
as  forthright  as  possible  in  their  rela¬ 
tionship.  For  instance,  if  the  Program 
Manager  foresees  a  circumstance  arising 
which  might  prevent  the  PM  from  obli¬ 
gating  funds  as  planned,  it  is  essential  to 
so  advise  the  comptroller.  This  is  good 
insurance,  for  at  some  later  date,  the 
Program  Manager  may  have  a  genuine 
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need  for  funds  which  the  PM  does  not 
have.  The  PM  is  much  more  likely  to 
get  a  sympathetic  hearing  from  the 
comptroller  if  there  has  been  coopera¬ 
tion  in  the  past. 

Other  individuals  outside  the  program 
office  who  can  be  of  great  help  to  the 
Program  Manager  are  the  action  officers 
on  the  service  headquarters  staffs  who 
monitor  acquisition  programs.  (The  ti¬ 
tles  and  roles  of  these  staff  coordinators 
are  discussed  in  Chapter  5,  "Program 
Review").  In  matters  of  planning,  pro¬ 
gramming,  budgeting  and  program  re¬ 
view,  the  staff  action  officers  can  be 
instrumental  in  ensuring  that  the  pro¬ 
gram’s  interests  are  well  presented  and 
that  the  services’  internal  administrative 
requirements  are  met  in  a  timely  man¬ 
ner. 

Few  joint  programs  enjoy  single-source 
funding.  Funding  responsibility  for 
most  joint  programs  is  shared  by  the 
lead  and  participating  services.  Whereas 
joint  program  direction  often  emanates 
from  OSD,  funding  is  provided  by  the 
services,  subject  to  each  service’s  as¬ 
sessment  of  its  own  funding  priorities. 

The  funding  arrangements  for  a  joint 
program  are  normally  defined  in  the 
program  charter  or  in  a  memorandum  of 
agreement  (MOA)  between  the  services. 
If  neith  r  of  these  is  possible,  the 
funding  .  angements  should  be  defined 
in  MOA  between  the  joint  program 
manager  and  each  of  the  services. 

3.0  COST  ESTIMATING 

There  is  very  little  unique  about  esti¬ 
mating  the  costs  of  a  joint  program. 
Both  the  cost  estimating  requirements 
and  the  methodologies  available  for  sat¬ 
isfying  the  requirements  are  the  same  as 
those  for  single-service  programs.  The 
procedures  of  the  lead  service  should 
suffice,  except  for  estimating  the  sup¬ 


port  investment  and  operating  and  sup¬ 
port  portions  of  life  cycle  costs. 

The  services  operate  in  different  envi¬ 
ronments,  are  organized  to  accomplish 
different  missions,  and  support  their 
forces  differently.  The  implication  of 
these  differences  is  that  support  con¬ 
cepts  and  requirements  for  logistic  re¬ 
sources  vary  from  service  to  service, 
even  when  all  the  services  are  operating 
the  same  type  of  equipment.  Estimates 
of  support  investment  and  operating  and 
support  costs  must  reflect  those  varia¬ 
tions.  For  example,  the  equations  used 
to  estimate  the  cost  of  spare  parts  for  an 
avionics  equipment  on  an  Air  Force 
tactical  fighter  might  include  a  war  re¬ 
serve  spares  kit  (WRSK)  to  permit 
squadron  level  support  of  the  system 
during  the  first  30  days  of  a  deploy¬ 
ment,  however,  the  equations  used  to 
compute  the  cost  of  spare  parts  for  an 
identical  equipment  on  a  Navy  fighter 
might  include  requirements  to  support  a 
60-day,  aircraft  carrier  deployment. 
The  cost-estimating  technique  used  by 
the  joint  program  must  be  tailored  to 
satisfy  both  requirements. 

The  Program  Manager’s  Notebook^ 
provides  an  excellent  synopsis  of  the 
following  cost  estimating  methodologies: 
ANALOGY,  ENGINEERING,  PARA¬ 
METRIC,  EXTRAPOLATION  FROM 
ACTUALS.  These  techniques  are  nor¬ 
mally  associated  with  hardware  estimat¬ 
ing,  but  in  today’s  acquisitions  the  area 
of  SOFTWARE  COST  ESTIMATING  is 
equally  critical.  The  Program  Manager’s 
Notebook  also  addresses  the  subject  of 
Software  Costing. 


ESTIMATING  METHODOLOGIES. 

Figure  7-1  shows  a  typical  relationship 
between  cost  estimating  methodologies 
and  acquisition  phased 
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Analogy  -  Cost  estimating  by  analogy  is 
built  around  the  premise  that  there  ex¬ 
ists  a  previously  developed  similar  sys¬ 
tem,  subsystem,  or  component  for  which 
cost,  technical,  and  programmatic  in¬ 
formation  exists.  The  methodology  used 
to  estimate  the  new  system,  subsystem, 
or  component  is  to  adjust  the  old  item 
in  terms  of  increased  complexity,  tech¬ 
nical  parameters,  fiscal  years,  etc.,  and 
attempt  to  quantify  these  differences  in 
terms  of  costs.  This  method  is  used 
early  in  the  development  process  and 
therefore,  there  may  be  a  great  deal  of 
subjective  facto  s  which  will  contribute 
to  the  estimating  error.  As  an  example, 
what  does  the  statement,  "twenty  per 
cent  more  complex,"  mean  in  terms  of 
cost?  The  cost  estimator,  working  with 
the  engineer,  will  have  the  responsibility 
to  eliminate  as  much  of  the  uncertainty 
as  possible,  and  to  identify  where  the 
remaining  uncertainty  lies. 

Engineering  -  Engineering  estimates  are 
also  known  as  "bottoms  up"  estimates,  in 
that  the  direct  elements  of  cost  (direct 
labor,  materials,  other  direct  costs 
(ODCs),  and  applicable  indirect  burdens 
are  calculated  at  the  lowest  task  level 
possible.  These  low-level  work  break¬ 
down  structure  estimates  are  then 
summed  to  yield  the  total  estimate.  The 
errors  which  are  made  in  estimating  the 
direct  labor  for  a  given  task  will  com¬ 
pound  itself  because  of  the  application 
of  indirect  burden's.  Other  problems 
arise  in  the  estimation  of  the  amount  of 
technical  risk,  which  can  translate  into 
rework  and  redesign.  Primarily  for  this 
reason  ENGINEERING  estimating  is 
most  applicable  to  the  production  phase 
and  subsequent  changes  to  the  system. 

Parametric  -  Parametric  cost  estimating 
is  widely  used  in  government  and  in¬ 
dustry  because  it  relies  on  mathematical 
analyses  of  data  and  the  development  of 
a  Cost  Estimating  Relationship  (CER). 
A  data  base  is  required  which  can  be 
used  to  relate  cost  to  technical  parame¬ 


ters,  and  then,  from  a  set  of  cost  and 
technical  parametric  relationships,  a 
CER  is  derived.  For  example,  there 
may  be  ten  missile  systems  which  can  be 
organized  into  tables  which  show  cost, 
weight,  speed,  and  guidance  type.  From 
these  tables,  an  equation  can  be  derived 
which  gives  cost  as  a  function  of 
weight,  speed  and  guidance  type.  This 
can  then  be  used  to  estimate  the  cost  of 
a  new  missile  system. 

Problems  exist,  however,  in  attempting 
to  extrapolate  beyond  the  range  of  the 
data  or  into  new  technological  areas. 
Care  must  be  taken  to  ensure  that  the 
factors  for  all  the  systems  in  the  data 
base  can  be  "normalized"  to  a  common 
fiscal  year,  unit  (first  unit  cost  is  nor¬ 
mally  used),  and  cost  content  (do  the 
costs  include  transportation  costs  or  not, 
for  example.) 

Extrapolation  from  Actuals  -  This  is 
similar  to  the  analogy  method  of  esti¬ 
mating  except  the  analogous  system  is  a 
prior  or  even  Hie  system  being  esti¬ 
mated.  Actual  cost  data  is  used  and 
adjusted  to  reflect  changes,  in  the  case 
of  a  subsequent  version,  or  used  as  the 
departure  point  to  estimate  the  remain¬ 
ing  cost  of  a  system  prototype,  for  ex¬ 
ample. 

The  method  used  in  estimating  the  cost 
of  a  system  should  be  based  upon  the 
amount  of  actual  data  available,  the  de¬ 
gree  of  commonality  between  the  new 
system  and  the  data,  and  a  thorough  un¬ 
derstanding  of  the  programmatic  dif¬ 
ferences  between  the  systems  in  the  data 
base  and  the  new  acquisition. 

SOFTWARE  COST  ESTIMATING 

Software  cost  estimating  is  a  complex 
and  little  understood  area.  A  brief  set 
of  important  issues  are  presented  below 
in  order  to  focus  attention  on  the  prob¬ 
lem.  One  of  the  most  widely  used  ref¬ 
erences  on  the  subject  is  Software  Ensi- 


Jieennft  ,  Economics,  by  Barry  w. 
Boehm",  which  should  be  required 
reading  for  software  cost  estimators. 
Some  of  the  more  important  software 
items  are: 

•  Underestimation  of  the  size  of  the 
software  development  is  a  key  factor  in 
misestimation 

«  The  definition  of  "size"  is  not  stan¬ 
dard  in  data  bases 

•  There  is  little  experience  in  costing 
new  high  level  languages 

•  Software  maintenance  is  extremely 
expensive  and  difficult  to  estimate 

•  The  current  trend  in  estimating  is 
moving  towards  costing  by  function 
(target  acquisition,  data  base  inversion, 
etc.) 

•  Productivity  rates  may  vary  widely 
with  language  and  function 

The  Financial  Manager  needs  to  be  es¬ 
pecially  aware  of  estimated  resources  for 
software  development  and  maintenance, 
and  appreciate  the  potential  for  large 
cost  uncertainties. 

4.0  COST  TERMS 

There  are  seven  cost  terms  which  have 
definitions  prescribed  by  DoDI 
5000.33-/  which  shall  be  used  when 
submitting  cost  information  to  OSD  for 
transmittal  to  Congress  or  other  govern- 
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tions  are  as  follows: 

Development  Cost  -  Development  Cost 
includes: 

(1)  Work  Breakdown  Structure 
(WBS)  elements  of  Major  System 
Equipment,  System/Project  Manage¬ 
ment,  System  Test  and  Evaluation 
(exccp*  Operational  Test  and  Evaluation 


funded  from  Military  Personnel  or  Op¬ 
eration  and  Maintenance  appropriation), 
Training,  Peculiar  Support  Equipment, 
Data,  Operational/  Site  Activation  and 
Industrial  Facilities  (when  provisions  of 
Chapter  251  of  DoD  Manual  71 10.1 -M27 
apply); 

(2)  RDT&E  funded  costs  (i.e.,  con¬ 
ceptual,  validation,  full  scale  develop¬ 
ment  phases  from  the  point  the  pro¬ 
gram/system  is  designated  by  title  as  a 
Program  Element  or  major  project  in  a 
Project  Element);  and 

(3)  All  costs,  both  contract  and  in- 
house,  of  the  Research  and  Development 
cost  category,  including  the  cost  of  spe¬ 
cialized  equipment,  instrumentation,  test 
and  facilities  required  to  support 
RDT&E  contractor  and/or  Government 
installation. 

Flyaway  (Rollaway,  Sailaway,  etc.)  Cost 
-  Flyaway  is  used  as  a  generic  term  re¬ 
lated  to  the  creation  of  a  usable  end 
item  of  hardware/softwaie.  Flyaway 
cost  includes: 

(1)  WBS  elements  of  Major  System 
Equipment  (such  as  basic  structure, 
propulsion,  electronics,  including  Gov¬ 
ernment  Furnished  Equipment,  etc.). 
System/Project  Management,  and  System 
Test  and  Evaluation  (if  any  of  this  ef¬ 
fort  is  funded  by  Procurement). 

(2)  Procurement  funded  costs  (i.e.. 
Line  Item  Procurement  Program);  and 
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house,  of  the  Production  Nonrecurring 
and  Recurring  cost  categories,  including 
allowances  for  engineering  changes, 
warranties,  and  first  destination  trans¬ 
portation,  unless  the  latter  is  a  separate 
budget  line  item. 

Weapon  System  Cost  -  Weapon  System 
Cost  includes: 
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(1)  The  same  WBS  elements  as  in 
Flyaway  Cost  (i.e.,  Major  System 
Equipment,  System/Project  Manage¬ 
ment,  System  Test  and  Evaluation  (if 
any  of  this  effort  is  funded  by  Pro¬ 
curement)),  plus  WBS  elements  Training, 
Peculiar  Support  Equipment,  Data,  Op¬ 
erational/Site  Activation  and  Industrial 
Facilities  (unless  funded  as  a  separate 
budget  line  item  or  by  RDT&E). 

(2)  Procurement  funded  costs;  and 

(3)  All  costs,  both  contract  and  in- 
house,  of  the  Production  Nonrecurring 
and  Recurring  cost  categories,  including 
allowances  for  engineering  changes, 
warranties,  and  first  destination  trans¬ 
portation,  unless  the  latter  is  a  separate 
budget  line  item. 

Procurement  Cost  -  Procurement  cost 
includes: 

(1)  The  same  WBS  elements  as  in 
Weapon  System  Cost  (i.e.,  Major  System 
Equipment,  System/Project  Manage¬ 
ment,  System  Test  and  Evaluation  (if 
any  of  this  effort  is  funded  by  Pro¬ 
curement)),  Training,  Peculiar  Support 
Equipment,  Data,  Operational/Site  Acti¬ 
vation,  and  Industrial  Facilities  (unless 
funded  as  a  separate  budget  line  item  or 
by  RDT&E),  plus  the  WBS  element:  Ini¬ 
tial  Spares  and  Initial  Repair  Parts; 

(2)  Procurement  funded  costs;  and 

(3)  All  costs,  both  contract  and  in- 
house,  of  the  Production  Nonrecurring 
and  Recurring  cost  categories,  including 
allowances  for  engineering  changes, 
warranties,  and  first  destination  trans¬ 
portation,  unless  the  latter  is  a  separate 
budget  line  item.  For  Navy  shipbuild¬ 
ing  programs,  outfitting  and  post  deliv¬ 
ery  costs  are  also  included  when  Pro¬ 
curement  funded. 

Program  Acquisition  Cost  -  consists  of 
Development  Costs,  Procurement  Costs, 


and  any  construction  costs  which  are  in 
direct  support  of  the  system  or  project. 
Program  Cost  and  Program  Acquisition 
Cost  are  synonymous  terms.  Program 
Acquisition  Cost  includes: 

(1)  The  WBS  elements  of  Major 
System  Equipment,  System/Project 
Management,  System  Test  and  Evalua¬ 
tion  (except  Operational  Test  and  Eval¬ 
uation  funded  from  Military  Personnel 
or  Operation  and  Maintenance),  Train¬ 
ing,  Peculiar  Support  Equipment,  Data, 
Operational/  Site  Activation,  Industrial 
Facilities  (unless  funded  by  Procurement 
as  a  separate  budget  line  item),  and  Ini¬ 
tial  Spares  and  Initial  Repair  Parts; 

(2)  RDT&E,  Procurement  and  MIL- 
CON  funded  costs;  and 

(3)  All  costs,  both  contract  and  in- 
house,  of  the  Research  and  Development 
and  Production  (Nonrecurring  and  Re¬ 
curring)  cost  categories,  including  al¬ 
lowances  for  engineering  changes,  war¬ 
ranties,  and  first  destination  transporta¬ 
tion,  except  when  the  latter  is  a  separate 
budget  line  item 

Ownership  Cost  -  Ownership  cost  en¬ 
compasses  the  cost  elements  within  the 
Operations  and  Support  (O&S)  cost  cate¬ 
gory  exclusively.  O&S  costs  include 
those  costs  associated  with  operating, 
modifying,  maintaining,  supplying,  and 
supporting  a  weapon/support  system  in 
the  DoD  inventory. 

(1)  Included  are  costs  for  skill 
training,  personnel  movement,  replen¬ 
ishment  spares  and  repair  parts. 

(2)  Operations  and  Maintenance 
(O&M),  Military  Personnel,  Procure¬ 
ment,  Military  Construction,  other  ap¬ 
propriations  and  funds  (stock  fund)  are 
used  to  operate  and  support  DoD 
weapon/support  systems. 
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Life  Cycle  Cost  -  Life  Cycle  Cost  in¬ 
cludes  all  WBS  elements;  all  related  ap¬ 
propriations;  and  encompasses  the  costs, 
both  contract  and  in-house,  for  ail  cost 
categories.  It  is  the  total  cost  to  the 
Government  for  a  system  over  its  full 
life,  and  includes  the  cost  of  develop¬ 
ment,  procurement,  operating,  support, 
and,  where  applicable,  disposal. 

Figure  7-2  shows  the  relationship  among 
the  above  cost  categories. 

5.0  FINANCIAL  MANAGEMENT 
INFORMATION  SYSTEMS 

With  the  widespread  use  of  microcom¬ 
puters  in  the  program  office,  there  has 
been  a  dramatic  rise  in  the  number  and 
quality  of  program  office  Financial 
Management  Information  Systems 
(FMIS). 

These  systems  have  been  designed  to 
take  advantage  of  the  power  of  new 
microcomputers  and  commercial  soft¬ 
ware  products,  One  specific  system  was 
designed  and  developed  by  a  joint  pro¬ 
ject  office  of  the  World  Wide  Military 
Command  Control  System  (WWMCCS) 
Information  System  (WIS)  Program.  The 
system,  called  RMIS,  for  Resource 
Management  Information  System,  was 
designed  around  a  commercial  data  base 
to  be  run  on  a  popular  microcomputer 
configuration. 

RMIS  consists  of  three  modules:  I  -  ap¬ 
proved  funding  by  service/agency,  fund 
type,  purpose,  and  fiscal  year;  II  -  es¬ 
timated  costs  in  terms  of  particular  site 
configuration  over  the  life  cycle  of  the 
program;  and  III  -  financial  planning 
and  execution  -  this  module  integrates 
the  available  funds  from  Module  1  and 
the  requirements  from  Module  II  and 
tracks  the  committed,  obligated,  and  ex 
pended  funds  along  with  the  approved 
funding  level. 


RMIS  is  an  example  of  a  powerful  sys¬ 
tem  which  can  be  of  great  help  to  a 
joint  program  office.  A  further  de¬ 
scription  of  RMIS  may  be  found  in  the 
September  1985  issue  of  the  "Journal  of 
Parametrics."^ 

6.0  SUMMARY 

This  chapter  has  discussed  the  role  of 
the  financial  manager  in  the  joint  pro¬ 
gram  office,  cost  estimating  methodolo¬ 
gies,  a  discussion  of  cost  definitions,  and 
an  example  of  an  automated  financial 
information  system.  Major  chapter 
points  include: 

•  the  breadth  of  the  financial  man¬ 
ager’s  activities, 

•  a  discussion  of  the  four  estimating 
techniques, 

•  definitions  of  the  seven  uniform 
cost  definitions,and 

•  a  discussion  of  an  automated  FMIS. 
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CHAPTER  8 

ENGINEERING,  PRODUCTION,  AND  SOFTWARE  MANAGEMENT 


1.0  SYNOPSIS 


2.0  ENGINEERING  MANAGEMENT 


The  three  areas  of  management,  engi¬ 
neering,  production,  and  software,  are 
vital  to  the  success  of  any  major  acqui¬ 
sition  program.  Success,  as  in  any 
management  effort,  is  effective  plan¬ 
ning,  execution  and  follow'  through 
which  transforms  a  military  requirement 
into  an  operational  system.  Engineering 
management  includes  the  system  engi¬ 
neering  process  of  a  logical  sequence  of 
events  and  decisions  tranforming  an 
operational  need  into  a  description  of 
system  performance  parameters  and  a 
preferred  system  configuration  including 
all  hardware  and  embedded  software  re¬ 
quirements.  Production  management 
objectives  are  to  accomplish  production 
planning  during  the  development  phase 
of  the  acquisition,  evaluate  production 
criteria  prior  to  the  decision  to  produce, 
and  subsequently  monitor  the  production 
effort  to  ensure  that  it  is  efficient  and 
effective.  Software  management  contin¬ 
ues  to  become  more  and  more  critical  to 
the  success  of  a  program  as  military 
weapon  systems  become  more  sophisti¬ 
cated  and  automated.  Significantly, 
more  effort  and  costs  aie  involved  in 
the  design,  development  and  testing  of 
software  than  the  system  within  which  it 
operates.  Certain  aspects  of  joint  ser¬ 
vice  acquisitions  can  benefit  the  man¬ 
agement  of  such  systems,  while  other 
aspects  dictate  the  need  for  more  man¬ 
agerial  attention.  Accordingly,  the  fol¬ 
lowing  sections  of  this  chapter  discuss 
various  aspects  of  the  three  management 
areas.  Section  2.0  discusses  engineering 
management.  Production  management  is 
presented  in  section  3.0  and  software 
management  is  discussed  in  section  4.0. 
Finally,  a  summary  of  the  chapter  is 
provided  in  section  5.0, 


More  information  is  available  on  the 
subject  of  engineering  management  then 
on  any  other  aspect  of  joint  service  ac¬ 
quisitions.  Guidance  and  procedures 
range  from  the  Federal  Acquisition 
Regulation  (FAR)  to  DoD  and  service 
directives,  instructions,  regulations,  or¬ 
ders,  manuals  and  pamphlets,  including 
military  standards,  such  as  M1LSTD- 
499A  which  discusses  criteria  for  evalu¬ 
ating  engineering  planning  and  cutput.^ 
DSMC's  Systems  Engineering  Manage¬ 
ment  Guide  is  an  integrated  summary  of 
technical  management  methods  specifi¬ 
cally  designed  as  a  PMO  reference.^ 
Additionally,  there  is  a  multitude  of 
professional  reference  manuals,  books 
and  journals.  Certain  factors  in  engi¬ 
neering  management  can  benefit  a  joint 
program:  the  operational  requirement, 
which  should  be  well  developed  as  a 
result  of  the  participating  services  in¬ 
teraction;  the  acquisition  strategy,  which 
also  provides  direction  to  engineering 
management,  as  in  the  case  of  Pre¬ 
planned  Product  Improvement  (PSI) 
should  be  integrated  into  the  engineering 
planning,  thus  enhancing  the  manage¬ 
ment  effort.  Likewise,  the  establish¬ 
ment  of  common  standards  in  engineer¬ 
ing  disciplines  will  facilitate  representa¬ 
tives  of  participating  services  to  com¬ 
prehend  the  core  requirements  for  spe¬ 
cific  functions.  For  example,  reliability 
programs  in  all  services  are  based  on 
M1LSTD-785B  and  maintainability  'pro- 
grams  should  comply  with  MILSTD- 
470A.2/1/ 

Further,  DoD  Directives  such  as  DoDD 
4120.11,  5000.40,  and  5000.43  provide 
guidance  lor  the  tailoring  of  standards, 
specifications  and  related  docu¬ 
ments.-^-^  These  directives  require 
the  modification  of  referenced  system 
documentation  to  meet  the  development 
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and  management  needs  of  the  acquisi¬ 
tion.  An  example  of  the  tailoring  of 
standards  and  specifications  is  the  Air 
Force’s  MIL-PRIME  Program.  The 
philosophy  of  the  program  is  to:  pre¬ 
pare  documents  that  represent  the  best 
starting  point  for  tailoring  documents 
for  a  specific  program;  state  only  per¬ 
formance  requirements,  »'.c\,  defining 
performance  parameters  and  leaving 
specific  values  blank;  reduce  the  refer¬ 
enced  specifications;  and  retain  "lessons 
learned"  in  a  non-contractual  appendix 
to  assist  in  tailoring.  As  of  May  1987, 
ASD  has  released  fifty-four  (54)  tailored 
MIL-SPECs  and  MIL-STDs.  The  po¬ 
tential  for  both  management  and  cost 
effectiveness  can  be  illustrated  by  the 
reduction  of  the  number  of  specifica¬ 
tions  required  for  a  landing  gear.  Be¬ 
fore  MIL-PRIME,  it  required  thirteen 
(13)  specifications  that  referenced  256 
technical  documents.  After  the  imple¬ 
mentation  of  MIL-PRIME,  it  only  ne¬ 
cessitated  the  use  of  one  specification 
that  referenced  two  technical  documents. 
The  Army  and  the  Navy  are  also 
streamlining  a  number  of  their  standards 
and  specifications  for  designated  pro¬ 
grams.  Along  with  the  number  of  ben¬ 
efits  that  can  be  cited  for  tailoring,  a 
primary  caution  must  be  made  concern¬ 
ing  a  potential  for  oversimplification 
that  could  result  in  inadequate  contract 
specifications  and  the  development  of  a 
system  that  does  not  meet  its  operational 
requirements  objectives. 


DoDD  5000.43  of  15  January  1986,  per¬ 
taining  to  acquisition  streamlining, 
should  be  specifically  noted  since  it  em¬ 


phasizes  the  need  for  action  that  results 
in  more  efficient  and  effective  use  of 
resources  to  develop,  produce,  and  de¬ 
ploy  quality  defense  systems  and  prod¬ 
ucts.  This  includes  ensuring  that  only 
cost-effective  requirements  are  included, 
at  the  most  appropriate  time,  in  system 
and  equipment  solicitations  and  con¬ 
tracts.  Also  as  part  of  the  streamlining 
effort,  the  directive  recommends  tailor¬ 


ing  the  data  requirements  by  determin¬ 
ing  the  essentiality  of  potential  Contract 
Data  Requirements  List  (CDRL)  items. 
In  this  regard,  for  example,  SEC- 
NAVINST  4210.6-/  specifies  that  prior 
to  a  program  entering  Full  Scale  Engi¬ 
neering  Development  (FSED)  the  Speci¬ 
fication  Control  Advocate  General 
(SPECAG)  must  certify  that  the  devel¬ 
opment  specifications  including  the 
CDRL,  have  been  reviewed  and  tailored 
to  the  operational  requirements.  In  ad¬ 
dition  to  tailoring,  an  alternative  ap¬ 
proach  to  improving  the  cost  effective¬ 
ness  in  the  utilization  of  military  speci¬ 
fications  and  standards  has  been  pro¬ 
posed  that  is  referred  to  as  "partitioning" 
which  may  also  be  considered  for  ap¬ 
plication  by  the  joint  program  manager. 
(See  reference  9.) 

In  the  acquisition  process,  sometimes  the 
first  evidence  of  weapon  system  prob¬ 
lems  does  not  become  apparent  until  a 
program  transitions  from  Full-Scale  De¬ 
velopment  (FSD)  into  Production.  This 
critical  risk  area  has  been  studied  and  it 
has  been  determined  that  the  risks  are 
the  result  of  technical  aspects  of  the  ac¬ 
quisition  rather  than  managerial.  In  an 
effort  to  reduce  the  risks  of  program 
transitions  as  much  as  possible,  DoD  has 
promulgated  DoDD  4245.7  which  man¬ 
dates  the  use  of  its  associated  manual, 
DoD  4245.7-M.i2/ii/  The  manual. 
Transition  from  Development  to  Pro¬ 
duction,  provides  Program  Managers 
with  assistance  in  structuring  technically 
sound  programs,  assessing  their  risk,  and 
identifying  areas  needing  corrective  ac¬ 
tion  through  the  use  and  application  of 
Templates.  The  Templates  describe 
techniques  for  improving  the  acquisition 
process  by  recognizing  it  for  what  it  is  - 
an  industrial  process  concerned  with  the 
design,  test,  and  production  of  low  risk 
products, 

Configuration  Control.  One  facet  of 
engineering  management  that  will  re¬ 
quire  increasing  attention  by  the  joint 
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program  manager  is  the  need  to  control 
engineering  changes.  Of  the  many  fac¬ 
tors  which  contribute  to  the  pressure  for 
engineering  changes  in  system  design, 
three  are  significant  and  interrelated: 

«  First,  validated  changes  to  system 
requirements  by  the  sponsoring  organi¬ 
zations  inevitably  lead  to  changes  in  the 
system  design.  The  joint  program 
manager  should  be  especially  alert  to 
these  and  must  require  that  sponsors 
recognize  that  incrementally  changed  re¬ 
quirements  can  bring  about  a  virtually 
new  program. 

•  Second,  pressure  for  change  comes 
from  the  technology  community  -  gov¬ 
ernment  and  contractor  laboratories  - 
who  find  a  better  way  to  accomplish  the 
original  requirement  after  acceptance  of 
a  preliminary  design,  Developmental 
tests  will,  of  course,  biing  to  light  those 
system  specifies  which  require  change  to 
allow  the  system  to  work. 

•  The  third  source  of  pressure  to 
change  a  design  is  not  really  separate 
from  the  first  two  at  all.  It  is  the 
seemingly  geometric  rate  of  technologi¬ 
cal  advancement  in  today’s  world  whch 
would  require  a  system  to  be  conceived, 
designed,  tested,  produced,  and  fielded 
in  a  year  to  prevent  its  obsolescence 
before  deployment.  It  is  this  last  pres¬ 
sure  which  will  cause  a  program  never 
to  reach  fruition  if  the  program  manager 
cannot  resist  incorporating  every 
"improving"  change. 

The  joint  program  manager  may  get 
more  pressure  for  changes  in  system  de¬ 
sign  than  will  a  single-service  program 
manager  because  of  requirements 
changes  from  the  participating  services. 
Well-defined  requirements  and  the 
problems  stemming  from  failure  to 
achieve  them  prior  to  engineering  devel¬ 
opment  are  addressed  in  Chapter  3. 
Changing  requirements  cannot  be  han¬ 
dled  by  configuration  control  board 


procedures,  but  the  sponsors’  knowledge 
of  the  program  manager’s  resistance  to 
unnecessary  change  may  prevent  incre¬ 
mental  requirements  upgrading  from 
gathering  momentum.  In  this  regard, 
the  program  manager  should  ensure  that 
the  PM’s  staff  has  effectively  baselined 
the  system  to  be  acquired  in  accordance 
with  DoD  Directive  5000.45,  "Baselining 
of  Selected  Major  Systems,”  25  August 
1986  and  related  Service  directives. 

It  is  axiomatic  in  the  field  of  program 
management  that  risk  and  commitment 
have  an  inverse  relationship  throughout 
the  acquisition  process.  The  program 
manager  may  consider  tying  the  param  ¬ 
eter  "resistance  to  change"  to  that  of 
commitment  in  the  program  management 
plan  so  that  at  each  succeeding  devel¬ 
opment  milestone,  as  risk  is  expected  to 
decrease,  resistance  to  change,  as  well  as 
commitment,  is  expected  to  increase. 
The  recognition  of  such  a  management 
policy  by  sponsors,  developers,  and 
contractors  will  preclude  their  interpre¬ 
tation  of  the  joint  program  manager’s 
early  seeking  of  innovation  as  continu¬ 
ing  acceptance  of  change. 

Primary  guidance  regarding  risk  man¬ 
agement  is  provided  in  the  following 
references: 

•  DoD  Directive  4245.7,  "Transition 
from  Development  to  Production,"  19 
January  1984; 

o  DoD  Manual  4245.7,  "Transition 
from  Development  to  Production," 
September  1985;  and 

o  "Risk  Assessment  Techniques," 
DSMC,  July  1983. 

3.0  PRODUCTION  MANAGEMENT 

Production  management  is  defined  as 
the  effective  use  of  resources  to  pro¬ 
duce,  on  schedule,  the  required  number 
of  end  units  that  meet  specified  quality, 
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performance,  and  cost.  The  field  of 
production  management  encompasses  in¬ 
dustrial  resource  analysis,  producibility 
assessment,  producibility  engineering 
and  planning,  production  engineering, 
industrial  preparedness  planning,  post- 
production  planning,  and  productivity 
enhancement.  Its  goals  are  to: 

•  accomplish  production  planning 
during  the  development  phase  of  the  ac¬ 
quisition, 

e  document  and  review  pertinent  pro¬ 
duction  criteria  before  the  decision  to 
produce  is  made,  and 

«  monitor  the  production  program 
once  it  is  implemented. 

DoD  Directive  4245.6  provides  the 
overall  policy,  procedures,  and  responsi¬ 
bilities  for  production  management  in 
the  Department  of  Defense  during  the 
acquisition  of  defense  systems  and 
equipment.—/  Production  management 
efforts  should  incorporate  the  following 
coupled  with  the  application  of  the 
Templates  mandated  by  DoD  Manual 
4245. 7-M: 

•  Emphasis  should  be  placed  on  the 
application  of  fundamental  engineering 
principles  and  relevant  technical  disci¬ 
plines  during  development  and  produc¬ 
tion.  Assessment  of  production  risks 
should  be  made  throughout  the  acquisi¬ 
tion  process  and  should  be  formalized 
through  Industrial  Resource  Analyses 
(IRAs)  and  Production  Readiness  Re¬ 
views  (PRRs).  Likewise,  risks  should  be 
reduced  to  acceptable  levels  in  accor¬ 
dance  with  DoD  Directive  4245.7  and 
DoD  Manual  4245. 7-M. 

«  A  manufacturing  strategy  should  be 
developed  as  part  of  the  program  acqui¬ 
sition  strategy.  Manufacturing  voids, 
deficiencies,  and  dependencies  on  criti¬ 
cal  foreign  source  materials  should  be 
addressed  concurrently  with  concept 


demonstration  and  validation  through 
the  use  of  manufacturing  technology 
projects  in  accordance  with  DoD  In¬ 
struction  4200. 15-1— /,  or  other  means. 
The  producibility  of  each  system  design 
concept  should  be  evaluated  at  the  Full- 
Scale  Development  (FSD)  decision  point 
to  determine  if  the  proposed  system  can 
be  manufactured  in  compliance  with  the 
production  cost  and  industrial  base  goals 
and  thresholds. 

•  Contractor  past  performance  (to  the 
extent  that  it  has  a  bearing  on  the  con¬ 
cept  involved),  production  management 
capability,  quality  history,  and  the  po¬ 
tential  to  execute  the  production  pro¬ 
gram  should  be  among  those  factors  in¬ 
cluded  in  the  contractual  solicitations 
and  evaluated  thereafter  in  the  source 
selections. 

•  A  comprehensive  Producibility  En¬ 
gineering  and  Planning  (PEP)  program  is 
a  requisite  for  entering  FSD.  PEP  pro¬ 
grams  should  be  conducted  throughout 
FSD  and  should  contain  specific  tasks, 
measurable  goals,  and  a  system  of  con¬ 
tractor  accountability  to  ensure  a  timely 
and  economic  transition  from  the  devel¬ 
opment  to  the  production  phase  of  the 
program. 

e  A  quality  program  in  accordance 
with  DoD  Directive  4155,1^  should  be 
conducted  throughout  acquisition  and 
deployment.  Industrial  preparedness 
planning  should  be  integrated  effectively 
with  production  management  and  pro¬ 
duction  planning  under  DoD  Directive 
4005. 1.—/  Determinations  of  priorities 
and  allocations  should  be  within  the 
framework  of  the  lead  service’s  delega¬ 
tion  of  authority,  consistent  with  DoD 
Instruction  4400. l.^/  Bills  of  Materials 
should  be  pui chased  and  maintained  by 
the  lead  service  for  the  determination 
and  accountability  of  controlled,  strate¬ 
gic  and  critical  material  requirements. 
Accordingly,  material  reporting  to  DoD 
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on  joint  services  programs  will  be  ac¬ 
complished  by  the  lead  service. 

•  Production  decisions  under  consid¬ 
eration  at  the  Defense  Acquisition  Board 
(DAB)  review  or  other  OSD  program  re¬ 
view  should  include  an  evaluation  of  the 
findings  of  a  formal  Production  Readi¬ 
ness  Review  /T>  R)  that  was  planned 
and  conductor  accordance  with  DoD 
Instruction  5000.38.—/  The  PRR  should 
confirm: 

-  The  stability  and  producibility  of 
the  design. 

-  Progress  toward  meeting  1 -liability 
and  maintainability  characteristics, 

-  The  adequacy  of  supporting  manu- 
f<t'.  uring  technology. 

-  The  refinement  of  manufacturing 
methods,  techniques,  and  processes. 

-  The  suitability  of  manufacturing, 
cost,  and  quality  assurance  control  pro¬ 
visions. 

•  A r'  acquisition  should  not  proceed 
into  production  until  it  is  determined 
that  the  principal  contractors  have  the 
p'vCtal,  financial,  and  managerial  ca¬ 
t's  :»ty  to  meet  the  cost  and  schedule 
.  .mimitments  of  the  proposed  procure¬ 
ment  An  asressnunt  should  be  made  of 
the  contractors’  capabilities  to  meet 
sur,:’t.-  (peacetime)  and  mobilization 
^declared  national  emergency)  require¬ 
ments  and  theii  commitments  to  partici¬ 
pate  in  the  DoD  inJusirhl  preparedness 
production  planning  pregram  under  DoD 
Directive  4005.1.-' 

a  Competition,  value  engineering, 
tailoring  of  „pecificat'ons  and  standards, 
design-to-cost,  cost  benefit  and  trade¬ 
off  assessments,  preplanned  product  im¬ 
provements,  .  ultiyear  j'-ocuvemetU,  in¬ 
dustrial  modernization  incentives,  and 
other  techniques  should  be  used,  as  ap¬ 


propriate,  to  reduce  production,  operat¬ 
ing,  and  support  costs.  Standardization, 
commonality,  and  interchangeability 
should  be  promoted  throughout  the  ac¬ 
quisition  cycle  to  reduce  lead  time  and 
life-cycle  cost. 

•  Technical  data  packages  should  be 
developed  and  proven  by  means  of  pro¬ 
duction  demonstration  and  configuration 
audit,  consistent  with  competition,  com¬ 
ponent  breakout,  arm  r  jprocurement 
objectives. 

e  Continued  emphasis  should  be 
placed  on  life-cycle  cost  reduction  dur¬ 
ing  the  production  phase  through  the 
use  of  contractual  incentives  and  other 
means. 

*  Production  management  planning 
and  implementation  should  include  pro¬ 
visions  for  measuring  progress  in  meet¬ 
ing  design-to-cost  and  life-cycle  cost 
commitments. 

»  Selection  of  contracts  and  subcon¬ 
tracts  requiring  contractor  cost  and 
schedule  management  systems  to  comply 
with  the  DoD  Cost/Schedule  Control 
Systems  criteria  shall  be  made  in  accor¬ 
dance  with  DoD  Instruction  7000.2.^/ 
When  a  contractor  or  subcontractor  is 
not  required  to  comply  with  the  criteria, 
the  Cost  'chedule  Status  Report  ap¬ 
proach  to  performance  measurement  set 
forth  in  DoD  Instruction  700C.10— / 
normally  should  be  used. 

«  Production  engineering  and  man¬ 
agement  should  include  those  actions 
that  are  required  to  maintain  a  cap  bil- 
ity  to  produce  material  for  the  operation 
and  maintenance  of  equipment  after  the 
production  phase  is  complete  The 
planning  for  these  post-produc  j.i  ac¬ 
tivities  should  start  during  the  develop¬ 
ment  phase. 

.  ally,  production  management 
shov,.  „  be  addressed  specifically  at  each 


8-5 


program  milestone  decision  point  in  the 
major  system  acquisition  process  in  ac¬ 
cordance  with  DoD  Instruction 
5000.2.^ 

-  Milestone  I  -  Demonstration  and 
Validation.  Production  feasibility  of 
candidate  system  concepts  should  be  ad¬ 
dressed  and  areas  of  production  risk  de¬ 
fined.  Manufacturing  technology 
needed  to  reduce  production  risk  to  ac¬ 
ceptable  levels  should  be  identified. 
Preliminary  goals  and  thresholds  for 
production  cost  should  be  formulated. 
Preliminary  goals  and  thresholds  for  in¬ 
dustrial  base  capability  should  be  devel¬ 
oped  based  on  an  Industrial  Resource 
Analysis  (IRA). 

-  Milestone  II  -  Full-Scale  Develop¬ 
ment  IFSD1.  The  producibility  of  the 
design  approach  should  be  confirmed 
and  production  risk  determined  accept¬ 
able.  The  FSD  phase  shall  include  pro¬ 
visions  to  attain  producibility  ot  the 
production  design  using  cost-effective 
manufacturing  methods  and  processes. 
Resource  requirements  for  PEP,  long- 
lead  procurements,  critical  materials,  la¬ 
bor  skills,  facilities,  equipment,  and 
limited  production  should  be  identified 
and  programmed,  and  the  capability  to 
meet  production  unit  cost,  schedule  and 
surge  requirements  should  be  confirmed 
at  the  prime  and  key  subcontr-  levels. 

-  Milestone  III  -  Production  and  De¬ 
ployment.  Production  decisions  should 
be  supported  by  an  assessment  of  the 
program  readiness  for  production,  based 
on  a  formal  Production  Readiness  Re¬ 
view  (PRR).  The  PRR  should  include 
assessing  the  results  of  Producibility  En¬ 
gineering  and  Planning  (PEP)  effort  and 
manufacturing  technology  activities,  and 
plans  and  provisions  for  accomplishing 
cost  reduction  during  production  should 
be  described. 

There  are  a  considerable  number  of 
relevant  guides,  '  andbeoks,  pamphlets, 


and  reports  that  are  oriented  towards  the 
engineering  and  manufacturing  field  of 
military  acquisition  management.  Ex¬ 
amples  include: 

•  "System  Engineering  Management 
Guide,"  DSMC,  December  1986. 

«  "Manufacturing  Management  Hand¬ 
book  for  Program  Managers,"  2nd  Edi¬ 
tion,  DSMC,  July  1984. 

•  "Report  of  Defense  Science  Board 
Task  Force  on  Transition  of  Weapons 
Systems  from  Development  to  Produc¬ 
tion,"  Office  of  the  Under  Secretary  of 
Defense,  August  1983.  ADA  135-049, 

•  JLC’s  joint  regulation,  "Joint  De- 

sign-to-Cost  Guide,"  DARCOM  P700-6, 
AFLCP/AFSCP  800-19,  15  October 

1977. 

•  GAO  Report,  "Assessing  P  oduction 
Capabilities  and  Constraints  it.  he  De¬ 
fense  Industrial  Base,"  Report  PEMD- 
85-3,  4  April  1985. 

4.0  SOFTWARE  MANAGEMENT 

Control  of  the  development  of  software 
and  its  documentation  is  a  requirement 
which  has  become  more  significant  and 
demanding  with  the  increasing  degree  of 
incorporation  of  computer  technology 
into  military  systems.  The  voluminous 
and  esoteric  nature  of  computer  soft¬ 
ware  makes  its  management  extremely 
demanding.  The  joint  program  manager 
is  tasked  to  determine  and  direct  the 
steps  necessary  to  keep  the  software  de¬ 
velopment  from  becoming  an  impedi¬ 
ment  to  program  completion.  Addition¬ 
ally,  the  PM  must  ensure  that  the  po¬ 
tential  for  interserv'''ing  of  software  and 
transportability  arc  reviewed  and  that  all 
software  support  options  are  fully  ana¬ 
lyzed.  Of  all  the  tasks  performed  by  the 
PM,  one  of  the  most  important  entails 
working  closely  with  using  and  devel¬ 
oping  activities  to  ensure  that  the  re- 
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suiting  software  fulfills  its  designated 
requirements. 

DoD  Directive  5000.29  establishes  the 
policy  for  the  management  and  control 
of  computer  resources  during  the  devel¬ 
opment,  acquisition,  deployment  and 
support  of  major  defense  systems.22'* 
Although  the  directive  was  published 
over  a  decade  ago.it  is  still  effective  and 
has  been  augmented  by  two  DoD  stan¬ 
dards,  DoD-STD-2167A  on  defense 
system  software  development2^  and 
DoD-STD-2168  on  the  defense  system 
software  quality  program.22'*  In  addi¬ 
tion,  DoD  Directive  3405.2  directs  the 
use  of  Ada  as  the  single,  common,  high- 
order  programming  language  in  com¬ 
puters  integral  to  weapon  systems.2^ 

Software  development  is  usually  an  it¬ 
erative  process,  in  which  an  iteration  of 
a  so  ware  development  may  occur  more 
than  once  during  each  of  the  acquisition 
phases.  Figure  8-1  presents  a  typical 
software  acquisition  as  it  relates  to  the 
hardware  acquisition.  The  software  de¬ 
velopment  cycle  usually  includes  the 
following  six  phases: 

•  Software  Requirements  Analysis 

•  Preliminary  Design 

•  Detailed  Design 

•  Coding  and  Unit  Testing 

•  Computer  Software  Component 
(CoD)  Integration  and  Testing 

•  CSCI  Testing 

Each  iteration  of  the  software  develop¬ 
ment  cycle,  regardless  of  the  acquisition 
phase  in  which  it  occurs,  should  be  ini¬ 
tiated  by  the  allocation  of  system  re¬ 
quirements  to  the  software  or  a  subse¬ 
quent  revision  to  those  requirements. 
The  relationship  of  the  software  devel¬ 
opment  cycle  phases  with  the  products. 


reviews  and  audits,  baselines  and  Devel¬ 
opmental  Configuration  are  presented  in 
Figure  8-2.  The  figure  reflects  the  se¬ 
quential  phases  of  a  software  develop¬ 
ment  cycle,  as  well  as  the  documentation 
which  typically  exists  prior  to  initiating 
an  interation.  Figure  8-1  cites  the  vari¬ 
ous  reviews,  including  design  reviews. 
The  purposes  of  the  reviews  are  dis- 
cused  in  MIL-STD-1521B,  Technical 
Reviews  and  Audits  for  Systems, 
Equipments,  and  Computer  Programs 

The  joint  program  manager  should  un¬ 
derstand  that  not  only  is  software  devel¬ 
opment  an  iterative  process,  several  it¬ 
erative  development  efforts  of  various 
software  components  may  be  in  process 
at  the  same  time.  Each  iteration  may 
also  represent  different  version  of  the 
software.  Also  within  each  iteration, 
the  software  development  phases  typi¬ 
cally  overlap,  rather  than  form,  a  dis¬ 
crete  initiation  to  completion  sequence. 

5.0  SUMMARY 

•  Certain  factors  in  engineering 
management  can  benefit  a  joint  program 
such  as  a  well  developed  operational  re¬ 
quirement  as  a  result  of  Darticipating 
services  interaction,  use  PS1  in  engi¬ 
neering  planning,  the  establishment  of 
common  standards  that  facilitate  partici¬ 
pating  services  to  comprehend  the  core 
requirements  for  specific  functions. 

•  DoD  Directives  4120.11,  >v/00.40 
and  5000.43  provide  guidance  for  tai¬ 
loring  standards,  specifications  and  re¬ 
lated  documentations. 

o  Acquisition  streamlining  as  con¬ 
tained  in  DoD  Directive  5000.43  em¬ 
phasizes  the  need  for  action  that  results 
in  more  efficient  and  effective  use  of 
resources  to  develop,  produce  and  de¬ 
ploy  quality  defense  systems  and  prod¬ 
ucts.  This  includes  ensuring  that  only 
cost-effective  requirements  are  included, 
at  the  most  appropriate  time,  in  system 
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and  equipment  solicitations  and  con¬ 
tracts. 

•  Configuration  control  requires  the 
increased  attention  of  the  joint  program 
manager  especially  to  stabilize  the  sys¬ 
tem  requirements  and  design  to  the 
maximum  extent  possible,  and  to  effec¬ 
tively  control  all  changes. 

•  Production  management  is  the  ef¬ 
fective  use  of  resources  to  produce,  or 
schedule,  the  required  number  of  end 
units  that  meet  specified  quality,  per¬ 
formance,  and  cost. 
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•  The  goals  of  production  manage¬ 
ment  are  to:  accomplish  production 
planning  during  the  development  phase 
of  the  acquisition,  document  and  review 
pertinent  production  criteria  before  the 
decision  to  produce  is  made,  and  then 
monitor  the  production  program  once  it 
is  implemented. 


•  DoD  Directive  5000.29  establishes 
the  policy  for  the  management  and  con¬ 
trol  of  computer  resources  during  the 
development,  acquisition,  deployment 
and  support  of  major  defense  systems. 
In  addition,  two  DoD  Standards,  2167A 
and  2168,  complement  the  directive  by 
providing  detailed  procedures  for  the 
development  for  quality  software. 
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CHAPTER  9 
LOGISTICS 


1.0  SYNOPSIS 

As  with  each  acquisition  discipline,  joint 
programs  will  encounter  many  challenges 
in  the  field  of  logistics  due  to  the  vari¬ 
ety  of  logistic  management  concepts  of 
the  various  services.  Achievement  of 
logistic  supportability  must  be  accom¬ 
plished  and  necessitates  that  all  support 
requirements  be  considered,  planned  and 
budgeted  from  the  beginning  of  the  ac¬ 
quisition  process.  Logistics  management 
objectives  of  joint  programs  are:  eco¬ 
nomic  joint  performance  of  Integrated 
Logistics  Support  (ILS)  planning,  analy¬ 
sis  and  documentation;  to  satisfy  essen¬ 
tial  needs  of  each  of  the  participating 
services;  and  to  attain  established  readi¬ 
ness  and  supportability  objectives.^ 
This  chapter  discusses  primary  logistics 
planning  aspects  that  are  of  major  con¬ 
cern  to  the  joint  program  manager  and 
the  joint  ILS  manager,  as  well  as  the 
participating  services.  Section  2.0  dis¬ 
cusses  the  multiservice  acquisition  ILS 
program.  Section  3.0  discusses  Inte¬ 
grated  Logistics  Support  (ILS)  planning. 
Next,  several  logistics  support  planning 
and  management  tools  are  presented  in 
section  4.0.  Then,  a  summary  of  the 
chapter  is  provided  in  section  5.0. 

2.0  MULTISEllVICE  ACQUISITION 
ILS  PROGRAM! 

The  concepts  and  principles  of  Inte¬ 
grated  Logistic  Support  (ILS),  as  con¬ 
tained  in  DoD  Directive  5000.39^  and 
Joint  directive  developed  under  the  aus¬ 
pices  of  the  Joint  Logistic  Commanders 
-  AR700-  129./OPNAVINST  4105.2/AFR 
800-43/MCO  1 1310.86s7  should  be  used 
in  all  multiservice  acquisition  programs. 
The  ILS  regulations  of  the  involved 
services  will  be  complied  with  to  the 
maximum  extent  possible.  Where 
impasses  occur  between  service  unique 
ILS  policy  and  procedures,  the  order  of 


precedence  will  be  DoD  Directive 
5000.39,  next  the  Joint  ILS  directive 
cited  above,  and  then  the  lead  or 
executive  service  ILS  regulation.  The 
lead  service  should  make  every  effort  to 
accommodate  the  unique  requirements 
of  the  participating  services.  All  in¬ 
volved  services  should  standardize  ILS 
requirements  and  data  products  to  the 
maximum  extent  possible. 

The  overall  objective  of  an  ILS  program 
is  to  field  supportable  systems/equip¬ 
ment  in  the  planned  operational  envi¬ 
ronments  that  meet  established  sys¬ 
tem/equipment  requirements  or  System 
Readiness  Requirements  at  an  affordable 
Life-Cycle  Cost  (LCC). 

The  lead  service  should  designate  an  ILS 
manager,  prior  to  establishing  an  acqui¬ 
sition  strategy,  to  execute  the  ILS  pro¬ 
gram,  and  provide  support  to  the  joint 
program  manager  in  all  matters  related 
to  the  ILS  program.  The  ILS  manager 
should: 

•  Ensure  that  the  participating  Ser¬ 
vices  designate  an  ILS  focal  point  to 
serve  on  and  support  the  ILS  program. 

•  Prepare  an  ILS  program  Joint  Mem¬ 
orandum  of  Agreement  (JMOA)  in 
conjunction  with  participating  Services. 

•  Coordinate  with  and  include  par¬ 
ticipating  Services  in  all  major  ILS  pro¬ 
gram  decisions,  actions,  and  planning 
efforts. 

•  Ensure  that  procedures  for  de¬ 
termining  sources  of  funding  for  par¬ 
ticipating  Service-unique  ILS  require¬ 
ments  are  included  in  the  JMOA. 

9  Ensure  planning,  solicitation,  and 
contractual  documents  include  ILS  pro¬ 
gram  requirements.  In  conjunction  with 
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participating  Services,  identify  work 
unique  service  requirements,  mainte¬ 
nance  and  support  concepts,  and  data 
requirements  for  contractual  application. 

•  Identify,  control  and  document  an 
executive  Service  maintenance  and  sup¬ 
port  concept.  Ensure  the  participating 
Services  maintenance,  and  support  con¬ 
cept,  and  deployment,  transfer  or  field¬ 
ing  requirements  are  identified,  docu¬ 
mented,  and  provided  to  the  lead  Ser¬ 
vice  1LS  program  organization,  for  in¬ 
corporation  into  the  Joiijt  ILS  Plan 
(JILSP)  and  JMOA.  Ensure  the  plan¬ 
ning  process  accommodates  commonali¬ 
ties  and  legitimate  differences  between 
Service  concepts. 

The  participating  services  should  desig¬ 
nate  an  ILS  representative  to  support  the 
lead  service  ILS  manager.  If  possible, 
co-locate  participating  Service  II.S 
managers  with  the  lead  Service  ILS  pro¬ 
gram  office  when  warranted  by  program 
complexity  and  impact.  Further,  the 
participating  Service  ILS  manager 
should: 

•  Participate  in  preparation  of  re¬ 
quirements  identification  evaluation  and 
update  of  the  JILSP,  ILS  program 
JMOA,  and  program  planning,  solicita¬ 
tion,  and  contractual  documents. 

•  Identify,  document  and  provide 
Service  unique  ILS  programs  require¬ 
ments  and  maintenance  concept,  de¬ 
ployment  requirements,  and  support 
concepts  to  the  lead  Service  ILS  man¬ 
ager.  Ensure  legitimate  Service  differ¬ 
ences  in  support  requirements  are  iden¬ 
tified  and  accommodated  during  the 
support  planning  process. 

•  Define  procedures  for  determining 
source  of  funding  for  participating  Ser¬ 
vice  unique  requirements  as  included  in 
ILS  program  JMOA. 


•  Provide  members  on  the  ILS  Man¬ 
agement  Team  (ILSMT)  and  representa¬ 
tion  at  all  joint  meetings  such  as  ILSMT 
meetings,  in-process  reviews,  provi¬ 
sioning  conferences.  Logistic  Support 
Analysis  (LSA)  reviews,  technical  docu¬ 
ments  verification  and  reviews,  and  de¬ 
sign  reviews. 

The  participating  services  are  responsi¬ 
ble  for  ensuring  full  participation  in  the 
joint  ILS  program  management  and  ex¬ 
ecution.  Primary  aspects  of  the  joint 
ILS  effort  are  cited  below: 

LSA  Program.  The  ILS  Management 
Team  (ILSMT)  should  ensure  that  the 
application  of  MILSTD-1388-1 A^  and 
MILSTD-1388-2A^,  regarding  Logistic 
Support  Analysis  (LSA)  are  tailored 
based  on  the  complexity  and  ILS  pro¬ 
gram  requirements. 

Joint  ILS  Plan  (JILSP).  The  JILSP 
should  be  initiated  when  the  lead  Ser¬ 
vice  ILS  Manager  is  designated.  The 
plan  should  be  prepared  by  the  lead 
Service  in  conjunction  with  the  partici¬ 
pating  Services,  and  expanded  as  re¬ 
quired  by  the  lead  service.  Each  Service 
unique  ILS  program  planning  informa¬ 
tion  and  requirements  should  be  con¬ 
tained  in  a  separate  JILSP  annex. 

ILS  Eifl&ram  Joint. .  ..Memorandum  of. 

Agreement  fJMOA).  An  ILS  program 
JMOA  should  be  prepared  to  formalize 
the  responsibility  and  procedures  for 
joint  ILS  program  operation  and  should 
include  procedures  for  resolving  im¬ 
passes  between  the  Services  involved. 
The  ILS  Manager  for  each  involved  Ser¬ 
vice  should  sign  the  ILS  program  JMOA. 
The  ILS  program  JMOA  will  be  com¬ 
pleted  and  coordinated  within  150  days 
of  the  initiation  of  a  multiservice  acqui¬ 
sition,  JMOA  revisions  may  be  renego¬ 
tiated  at  any  time  during  the  sys¬ 
tem/equipment  acquisition  process.  The 
ILS  program  JMOA  will  be  attached  as 
an  annex  to  the  JILSP. 
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ILS  Elements.  A  single  set  of  ILS  ele¬ 
ments  should  be  identified  and  agreed  to 
during  formulation  of  the  ILS  program 
JMOA.  This  single  set  should  include 
all  the  ILS  elements  contained  in  DoDD 
5000.39  and  other  selected  ILS  elements 
contained  in  the  lead  and  participating 
Services  ILS  regulations.  The  JILSP  will 
cover  all  selected  ILS  elements. 

Ancillary  Eouinment.  Logistic  support 
for  ancillary  equipment  should  be 
planned  as  an  integral  part  of  the  mul¬ 
tiservice  system/equipment  acquisition 
effort. 

Intermediate  Support.  Joint  use  of  cen¬ 
tralized  intermediate  maintenance  facili¬ 
ties  should  be  encouraged  to  reduce  du¬ 
plication. 

Depot  Support.  Responsibility  for  depot 
repair  and  maintenance  should  be  as 
determined  by  the  Depot  Maintenance 
Interservice  (DMI)  study  (as  performed 
by  a  Joint  Depot  Maintenance  Analysis 
Group  (JDMAG)),  based  on  data  pro¬ 
vided  the  lead  Service. 

ILS  Management  Team  (ILSMT).  ILS 
Program  Organization.  An  ILSMT 
should  be  established  as  the  ILS  program 
organization,  and  meet  as  required  to 
assist  and  support  the  lead  Service  ILS 
manager  in  accomplishing  program  re¬ 
lated  ILS  functions.  The  ILSMT  should 
be  composed  of  members  from  both  lead 
and  participating  Services  and  chaired 
by  the  lead  Service  ILS  amanger.  An 
LSA  review  team  composed  of  govern¬ 
ment  ILS  and  logistic  element  represen¬ 
tatives,  headed  by  the  lead  Service  ILS 
manager,  should  be  established  as  part 
of  the  ILSMT. 

Unique  Service  Requirements  and  De¬ 
ployment  Requirements  or  Plans.  De¬ 
ployment  requirements/plans,  sys¬ 
tem/equipment  Material  Fielding  Plans, 
System  Turnover  Plan  (transition  plan), 
installation  plans,  and  other  such  Service 


plans  should  be  prepared  by  each  in¬ 
volved  Service.  If  no  single  format  is 
acceptable,  Service  unique  formats 
should  be  used.  When  Service  unique 
formats  are  used,  a  copy  should  be  pro¬ 
vided  to  the  lead  service  ILS  manager. 

ILS  Lessons  Learned.  Applicable  ILS 
lessons  learned  should  be  selected  by  the 
requiring  activity,  and  applied  both  to 
internal  ILS  program  management,  exe¬ 
cution  and  contractual  ILS  requirements. 
Feedback  should  be  provided  to  both 
lead  and  participating  Services  ILS 
lessons  learned  data  bases. 

Maintenance  Planning.  Specific  mainte¬ 
nance  concepts  for  each  Service  should 
be  documented  in  the  JILSP,  by  Mile¬ 
stone  I,  and  any  changes  should  be  ap¬ 
proved  by  the  ILSMT.  Maintenance 
concepts  and  planning  should  be  up¬ 
dated  prior  to  each  decision  point. 

multiservice  ILS  program  management 
and  execution,  a  listing  of  Service  ILS 
points  of  contact  should  be  maintained 
and  updated  as  required. 

Training.  Joint  use  of  centralized 
training  facilities  for  operator  and 
maintenance  training  should  be  encour¬ 
aged  to  reduce  duplication. 

JEyalUflticm-  Test  and  evalua¬ 
tion  criteria  will  evaluate  supportability 
and  ensure  representation  from  each 
participating  service  and  the  contractor 
to  review  supportability  issues/eval¬ 
uations.  Test  and  evaluation  criteria  (or 
plans)  should:  (1)  Ensure  participating 
Services  are  involved  in  developing 
supportability  test  issues  and  test  plans 
for  both  hardware  and  software;  and  (2) 
The  detailed  maintenance  planning  in 
the  JILSP  should  be  used  as  the  basis 
for  the  initial  Operational  Test  and 
Evaluation  (OT&E)  and  all  follow-on 
OT&E. 
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3.0  INTEGRATED  LOGISTICS 
SUPPORT  (ILS)  PLANNING 

The  Integrated  Logistics  Support  (ILS) 
planning  functions  are  essential  to  the 
successful  integration  of  an  equipment 
into  operational  use.  The  ILS  concepts 
must  be  initiated  in  conjunction  with 
the  equipment  design  concept.  The 
consideration  of  the  ILS  should  not  be 
postponed  beyond  the  development 
phases  because  the  interdependent  ILS 
tasks  will  be  little  more  than  analysis  of 
an  existing  design  to  determine  what 
must  be  done  to  support  it.  Rather,  the 
purpose  of  the  ILS  is  to  influence  design 
for  the  sake  of  readiness  and  support. 
Delay  causes  support  system  choices  to 
be  limited,  and  design  changes  expensive 
to  implement.  Therefore,  the  most  ef¬ 
fective  way  of  implementing  ILS  is  to 
design  it  into  the  evolving  equipment 
features  initially.  This  requires  inte¬ 
grated  planning  of  design  for  perfor¬ 
mance  and  design  for  support  concur¬ 
rently.  The  ILS  disciplines  include  the 
following:-'' 

•  Maintenance  Planning 

0  Manpower  and  Personnel 
0  Supply  Support 
0  Support  Equipment 
0  Technical  Data 
0  Training  and  Training  Support 
0  Computer  Resources  Support 

•  Facilities 

0  Packaging,  Handling,  Storage,  and 
Transportation 

0  Design  Interface 

Reliability  and  Maintainability,  while 
not  specifically  defined  as  logistics  ele¬ 


ments,  are  logistic-related  design  pa¬ 
rameters  which  must  be  expressed  early 
in  the  program  in  operational  terms,  and 
must  be  stated  as  design  requirements 
that  arc  specifically  targeted  to  achieve 
readiness  and  supportability  objectives. 

Operating  Concepts 

The  starting  point  for  logistics  planning 
is  an  understanding  of  how  the  equip¬ 
ment  will  be  used:  the  mission,  the  op¬ 
erating  environment,  the  tactical  de¬ 
ployment,  and  the  forces  that  will  use 
and  support  it.  It  is  essential  that  the 
operating  concept  be  prepared  for  each 
alternative  by  Milestone  I  and  finalized 
by  Milestone  II.  The  operating  concept 
should  be  clearly  understood  by  the 
joint  program  management  team. 

Logistics  planning  must  begin  at  the 
initial  program  milestone,  program 
initiation.  It  is  at  this  point  that  the 
mission  element  need  statement,  the 
Justification  for  Major  System  New 
Start  (JMSNS)  reflects  the  baseline 
equipment  operation  and  logistic  envi¬ 
ronment  established.  Each  decision 
milestone  requires  updated  logistics 
planning,  programming,  and  certifica¬ 
tion.  The  participating  services  should 
assist  in  formulating  an  initial  logistics 
planning  document,  such  as  the  Joint 
Integrated  Logistic  Support  Plan  (JILSP). 
Appendix  D  describes  the  recommended 
content  and  format  of  a  JILSP.  Given 
identical  equipments,  each  of  the  par¬ 
ticipating  services  may  employ  them 
differently,  thereby  generating  different 
logistics  requirements.  Thus,  their  dif¬ 
ferent  operating  concepts  could  influ¬ 
ence  the  equipment  and  support  system 
design  si,  lificantly.  The  JILSP  focuses 
management  attention  on  the  problems 
that  different  operating  concepts  may 
create  in  terms  of  equipment  design  and 
support  system  alternatives.  The  JILSP 
also  acts  as  a  cohesive  agent,  encourag¬ 
ing  the  services  to  establish  and  inte¬ 
grate  their  logistics  plans  early.  The 
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Integrated  Support  Plan  (ISP)  prepared 
by  the  contractor  should  complement  the 
JILSP  and  reflect  the  contractors  ap¬ 
proach  to  complying  with  the  logistics 
requirements  established  for  the  joint 
program. 

The  operating  commands  of  each  par¬ 
ticipating  service  determine  how  a  sys¬ 
tem  is  used.  In  the  Army,  the  Training 
and  Doctrine  Command  (TRADOC) 
normally  represents  the  eventual  user. 
In  the  Navy,  the  mission  sponsor  (<?.£., 
the  Deputy  Chief  of  Naval  Operations 
for  Air  Warfare)  usually  prepares  the 
plan  for  use  and  coordinates  it  with  the 
Fleets.  In  the  Air  Force,  the  using 
command  ( e.g .,  Tactical  Air  Command) 
participates  directly  in  the  acquisition 
program,  influencing,  among  other 
things,  how  the  new  system  will  be  em¬ 
ployed. 

Although  strongly  encouraged,  if  the 
user  (or  his  representative  in  the  acqui¬ 
sition  process)  does  not  advocate  an  op¬ 
erating  and  support  concept  the  joint 
program  manager  must  take  the  initia¬ 
tive.  As  the  program  progresses  through 
the  acquisition  process  and  the  equip¬ 
ment  design  and  capabilities  become 
better  defined,  firm  operating  and 
maintenance  plans  will  evolve.  If  these 
concepts  are  not  defined  early,  the  lo¬ 
gistics  planning  baseline  will  not  be 
properly  established,  and  program 
schedule  and  cost  could  be  adversely 
affected.  As  a  rule,  the  preponderant 
program  costs  of  ownership  are  locked 
in  as  design  is  being  frozen.  Since  this 
is  well  before  O&M,  costs  actually  be¬ 
gin,  logistics  R&D  tasks  offer  major  cost 
effectiveness  opportunities. 

Support  Concepts 

There  are  service  differences  in  practi¬ 
cally  every  aspect  of  support  -  the  orga¬ 
nizational  structures,  type  of  support 
available  at  each  level,  occupational 
skills,  training,  facilities,  lest  equipment. 


and  support  environment.  The  differ¬ 
ences,  though  not  significant  enough  to 
preclude  effective  support  of  virtually 
any  equipment  by  any  service,  may 
cause  a  serious  impact  to  the  preferred 
equipment  design  (especially  mainte¬ 
nance  characteristics),  or  the  range  of 
feasible  support  concepts,  and  the  sup¬ 
port  resource  requirements  of  each  par¬ 


ticipating  service. 
Support  Analysis 


Some  of  the  Logistic 
^  tasks,  performed 


during  R&D,  provide  the  trade-off 


analyses  needed  to  accommodate  these 


differences. 


The  services  recognize  three  levels  of 
maintenance:  organizational,  intermedi¬ 
ate  and  depot.  The  Marine  Corps  also 
has  three  levels  of  maintenance  for  air¬ 
craft,  however,  for  ground  equipment 
they  employ  four  levels:  organizational, 
direct  support,  general  support,  and  de¬ 
pot. 

It  might  appear  that  Army  direct  and 
general  support  are  comparable  to  Navy 
and  Air  Force  intermediate  maintenance, 
but  that  is  not  the  case.  Many  mainte¬ 
nance  tasks  done  at  the  direct  support 
level  in  the  Army  would  be  done  at  the 
organizational  level  in  the  Navy  or  Air 
Force.  Many  of  the  general  support 
tasks  would  be  done  at  the  Navy  or  Air 
Force  depot. 

The  intermediate  level  in  the  Navy  is 
not  always  similar  to  that  of  the  Air 
Force.  Ships,  for  example,  must  be 
largely  self-sufficient;  tasks  which 
would  be  intermediate  level  on  an  Air 
Force  system  might  be  considered  orga¬ 
nizational  ievei  on  a  ship  system.  Lven 
for  aircraft  and  aircraft  systems,  where 
the  similarities  among  the  services’ 
maintenance  structures  are  most  appar¬ 
ent,  there  are  major  differences  in  the 
environments,  facilities,  test  equipment, 
and  maintenance  skills  available  at  each 
level.  To  begin  to  appreciate  the  dif¬ 
ferences,  one  need  only  imagine  the 
maintenance  operations  on  a  pitching 
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rolling  deck  of  a  ship  or  a  hastily  pre¬ 
pared  jungle  base  compared  to  those  on 
an  established  air  field. 

There  are  frequently  also  differences 
among  the  services  in  the  proximity  of 
support  organizations  to  operating 
forces.  Because  of  those  differences,  a 
support  concept  which  would  provide 
one  service  with  acceptable  maintenance 
turn-around  times  may  be  unable  to 
support  the  desired  level  of  operational 
readiness  in  another  service. 

4.0  LOGISTICS  SUPPORT  TOOLS 

There  are  several  logistics  support  plan¬ 
ning  and  management  tools  to  assist  the 
joint  program  manager  and  staff  that  are 
discussed  below: 

Integrated  Logistics  Support  Plan 
(ILSP).  DoD  Directive  5000.3917  pro¬ 
vides  the  policy  and  responsibilities  for 
the  acquisition  and  management  of  Inte¬ 
grated  Logistics  Support  (ILS)  programs 
as  an  integral  part  of  the  acquisition 
process  and  emphasizes  the  need  for 
early  ILS  planning.  The  Program  Man¬ 
ager  should  develop  a  draft  Integrated 
Logistics  Support  Plan  (ILSP)  by  Mile¬ 
stone  I,  complete  it  by  Milestone  II,  and 
keep  it  current  throughout  the  acquisi¬ 
tion  process.  The  ILSP  shall  integrate 
the  logistics  aspects  of  the  program. 
Positive  controls  should  be  established  to 
integrate  schedules  and  to  identify  in¬ 
terdependencies  among  ILS  elements, 
design  activities  and  deployment  plans. 
The  ILSP  should  document  readiness  and 
support  objectives  and  demonstrated 
achievements,  Logistics  Support  Analysis 
(LSA)  strategy,  operating  concepts  and 
deployment  requirements  (including 
transportability),  support  concepts  and 
plans,  ILS  element  requirements,  sched¬ 
ule,  funding  requirements  and  responsi¬ 
bility  for  ILS  activity  planned  for  each 
program  phase.-7 


The  joint  program  manager  and  staff 
should  normally  prepare,  coordinate  and 
promulgate  an  initial  draft  ILSP  during 
the  Concept  Exploration  phase.  The 
draft  will  provide  a  basis  for  partici¬ 
pating  services  and  contractor  planning 
and  for  ILS  planning  in  subsequent  ac¬ 
quisition  phases.  By  Milestone  I,  the 
ILSP  should  include  specific  tasks  to  be 
accomplished  during  the  Demonstration 
and  Validation  Phase,  identify  the  re¬ 
sponsible  service  agencies  ahd  activities, 
and  establish  the  schedule  for  task  com¬ 
pletion.  The  ILSP  will  also  project  re¬ 
quirements,  tasks  and  milestones  for 
future  acquisition  phases. 

During  the  Demonstration  and  Valida¬ 
tion  phase  and  following  acquisition 
phases,  the  ILS  Manager  of  the  joint 
program  staff  may  obtain  contractor  as¬ 
sistance  to  review  and  update  the  ILbP. 
The  plan  will  become  progressively  more 
detailed  as  the  program  design  activity 
progresses.  Prior  -o  entering  the  Full 
Scale  Development  (FSD)  phase,  the  up¬ 
date  of  the  full  scope  ILSP  should  be 
completed  by  the  ILS  Manager.  The 
update  should  reflect  the  results  of  the 
demonstrations  and  validations,  include 
pertinent  details  from  the  contractor- 
prepared  Integrated  Support  Plan  (ISP), 
and  describe  the  plan  for  the  FSD  phase. 

During  FSD  and  in  subsequent  phases, 
the  ILSP  should  have  continuous  joint 
program  office  and  contractor  involve¬ 
ment  in  reviewing,  refining,  expanding, 
and  updating  the  plan.  The  IL  SP  should 
be  updated: 

e  When  new  program  direction  is  re¬ 
ceived. 

•  When  there  are  changes  that  involve 
personnel,  (raining,  facilities,  or  any 
other  ILS  elements. 

«  before  each  milestone  decision  re¬ 
view. 
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The  responsibility  of  the  joint  program 
office  is  to  ensure  that  all  milestones  are 
listed,  that  the  timing  is  correct,  and  co¬ 
ordination  actions  have  been  completed. 
The  contractor  should  provide  inputs  as 
appropriate  for  ILSP  updates.-/ 

The  content  and  format  of  the  ILSP 
should  be  tailored  by  the  joint  program 
ILS  staff  based  on  the  needs  of  the  spe¬ 
cific  program,  however,  each  of  the 
following  items  should  be  discussed  as 
appropriate  in  the  plan.-/-/ 

•  System  Description  including  Gov¬ 
ernment  Furnished  Equipment  (GFE), 
Government  Furnished  Material  (GFM) 
and  associated  support  items  of  equip¬ 
ment. 

•  Organizational  responsibilities  and 
relationships  of  agencies  and  organiza¬ 
tions  supporting  the  joint  program  of¬ 
fice. 

•  Operation. :l  and  Organisational 
Concept  involving  mission  requirements, 
operational  environment  and  other  re¬ 
quired  LSA  input  parameters. 

•  System  Readiness  Objectives  (SRO) 
for  both  peacetime  and  wartime  siica- 
tions 

®  Logistics  Acquisition  Strategy  in¬ 
volving  contractual  approaches  and  in¬ 
centives  fo.  LCC,  Reliability  &  Main¬ 
tainability  (R&M)  and  supportability 
goals. 

•  LSA  Plan  which,  due  to  its  impor¬ 
tance  in  realizing  program  and  ILSP 
objectives,  may  be  included  as  a  sepa¬ 
rate  document.  This  plan  describes  the 
approach  to  LSA  and  the  results  ex¬ 
pected. 

•  Supportability  Test  and  Evaluation 
Concepts  involving  identification  of 
specific  test  issues  related  to  overall  ILS 
objectives  and  to  each  !LS  element. 


•  ILS  Elements  should  be  addressed 
as  to  ILS  objectives,  concepts,  trade-off 
factors,  goals,  thresholds,  special  re¬ 
quirements,  responsibilities,  and  valida- 

'on  and  verification  requirements.  The 
manner  in  which  each  applicable  ele¬ 
ment  of  ILS  is  obtained  and  integrated 
with  the  other  elements  should  be  doc¬ 
umented. 

•  Support  Transition  Planning  de¬ 
scribing  the  plans  for  transition  from 
contractor  to  government  support.  The 
planning  should  involve  each  of  the  ap¬ 
plicable  ILS  elements. 

•  Support  Resource  Funds  involving 
ILS-related  life-cycle  funding  require¬ 
ments  (funded  and  unfunded)  should  be 
identified  by  ILS  element,  program 
function  and  appropriation  category. 

9  Post  Fielding  Assessments  involving 
plans  for  analyzi  g  and  assessing  field 
*  data  feedback  related  to  material  support 
and  support  system  performance.  The 
plans  should  address  assessment  metu.od- 
ology  identify  milestones  and  responsi¬ 
bilities  and  describe  the  strategies  for 
improvements. 

•  Milestone  Schedule  Charts  showing 
the  interrelationships  of  specific  logistic 
support  related  tasks  and  events  to  the 
overall  program  milestones  and  to  each 
other. 

Logistics  Support  Analysis  (LSA) 

The  Logistics  Support  Analysis  (LSA) 
program  is  described  in  MILS7D-1388- 
1A.-'  The  LSA  program  snail  be  estab¬ 
lished  as  an  integral  part  of  the  system 
engineering  process,  with  two  primary 
goals  in  mind:  first,  to  influence  system 
design  from  the  readiness  and  supporta¬ 
bility  point  of  view  (following  a  "top- 
down"  approach),  and  second,  to  iden¬ 
tify  logistic  support-related  resource  re¬ 
quirements  (using  a  "botto  ms-up"  ap¬ 
proach).  There  are  two  key  elements  of 
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the  LSA  process  that  contribute  to  the 
integration  process.  The  first  is  the  es¬ 
tablishment,  within  the  design  activity, 
of  logistics  oriented  tasks  that  are  di¬ 
rectly  relatable  to  such  engineering  ef¬ 
forts  as  reliability,  maintainability,  and 
standardization.  The  tasks  are  tailored 
to  the  specific  characteristics  of  the  en¬ 
gineering  program.  The  second  key 
element  is  the  development  of  validated, 
integrated  data  bases  and  other  sources 
of  LSA  documentation  that  can  provide 
an  audit  trail  for  design  analyses  and 
decision  rationales,  as  well  as  the  basis 
for  the  identification  ol'  supportability- 
related  resource  requirements.  The 
LSAR  provides  only  a  part  of  this  doc¬ 
umentation;  other  LSA  documentation 
must  be  specifically  identified  in  appli¬ 
cable  Data  Item  Descriptions  (DIDs)  and 
cited  in  the  Contract  Data  Requirements 
List  (CDRL)  for  each  individual  pro¬ 
gram.  The  data  system  provides  con¬ 
tractors  an  information  system  for  ac¬ 
complishing  system  engineering  and  is 
used  to  satisfy  government  data  re¬ 
quirements.  The  LSA  deserves  the 
highest  visibility  within  the  joint  pro¬ 
gram  office.  The  advantages  of  such  a 
common  data  base  for  individual  logis¬ 
tics  functions  include  reduced  costs, 
shorter  procurement  leadtimes,  and  sim¬ 
plified  data  maintenance  and  documen¬ 
tation.  In  a  joint  program,  there  is  the 
additional  advantage  of  spreading  the 
costs  of  developing  an  LSA  data  base 
over  two  or  more  services. 

Use  of  LSA  should  facilitate  the  con¬ 
solidation  of  the  various  data  require¬ 
ments  generated  by  the  participating 
services  into  a  single  cohesive  contrac¬ 
tual  record.  Although  the  consolidation 
of  the  requirements  may  appear  to  be 
difficult,  carefully  reviewing  each  ser¬ 
vice’s  requirements  and  allowing  the 
service  with  the  greatest  requirements 
prepare  a  single  set  of  contract  require¬ 
ments  is  a  suggested  approach. 


The  LSA  requirements  consist  of  five 
general  task  sections  involving  fifteen 
(15)  tasks  and  seventy-seven  (77)  sub¬ 
tasks.  The  five  general  task  sections  are 
discussed  below:— ^ 

•  Program  Planning  and  Control. 
Management  of  the  LSA  effort  requires 
the  development  of  a  proposed  LSA 
strategy,  tailoring  decisions,  require¬ 
ments  for  the  LSA  plan,  and  design  re¬ 
views,  procedures  and  schedules.  The 
LSA  planning  and  management  is  the 
responsibility  of  the  joint  program 
manager.  If  available,  the  ILSF  provides 
guidance  to  the  contractor. 

•  Mission  and  Support  System  Defi¬ 
nition.  The  LSA  effort  is  used  to  estab¬ 
lish  supportability  objectives  and  sup- 
portability  related  design  goals,  thresh¬ 
olds,  and  constraints  through  comparison 
with  existing  systems  and  analyses  of 
supportability,  cost,  and  readiness 
drivers. 

•  Preparation  and  Evaluation  Alterna¬ 
tives.  These  tasks  are  highly  iterative  in 
nature  and  are  applicable  to  successive 
phases  of  the  pre-production  part  of  the 
life  cycle  and  to  production  design 
changes.  The  tasks  are  generally  per¬ 
formed  in  sequence  and  the  process  is 
then  iterated  to  increasingly  lower  levels 
of  detail  in  conjunction  with  the  system 
engineering  process. 

•  Determination  of  Logistics  Support 
Resource  Requirements.  This  portion  of 
the  LSA  defines  the  requirements  of  the 
1LS  elements.  The  tasks  can  be  very 
costly  and  produce  a  considerable 
amount  of  documentation. 

9  Supportability  Assessment.  The 
supportability  test  ana  evaluation  pro¬ 
gram  is  a  vital  part  of  the  LSA  process 
throughout  a  program  life  cycle.  It 
should  serve  three  objectives:  (a)  pro¬ 
vide  measured  data  for  supportability 
design  parameters  as  inputs  to  the  sys- 
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tem  engineering,  Life-Cycle  Costs 
(LCC),  and  support  system  design  activ¬ 
ities,  (b)  present  supportability  problems 
for  corrective  action,  and  (c)  demon¬ 
strate  contractual  compliance  with  de¬ 
sign  requirements. 

Logistics  Support  Analysis  Record 
(LSAR) 

The  Logistics  Support  Analysis  Record 
(LSAR)  data  requirements  are  detailed 
in  MILSTD-1388-2A.^  The  LSAR  data 
are  a  subset  of  the  LSA  documentation 
and  are  generated  as  a  result  of  per¬ 
forming  the  logistic  support  analysis 
tasks  specified  in  MIL-STD-1388-1A. 
The  MIL-STD-1388-2A  is  structured  to 
accommodate  the  maximum  range  of 
data  potentially  required  by  all  services 
in  all  ILS  element  functional  areas  for 
all  types  of  material  systems,  and 
through  the  entire  acquisition  life  cycle. 
This  approach  permits  standardization  of 
formats  and  data  definitions  for  gov¬ 
ernment-required  LSA  data.  Tailoring 
of  these  data  requirements  is  a  vital  part 
of  the  ILS  effort.  There  are  fourteen 
(14)  LSAR  standard  data  records.  Fig¬ 
ure  9-1  identifies  these  fourteen  (14) 
data  records  and  relates  them  to  the  ap¬ 
plicable  LSA  tasks.  There  are  many 
LSA  tasks  that  are  not  documentated  by 
the  LSAR.  The  output  of  these  tasks 
may  be  docume  ’ts  such  as  the  contrac¬ 
tor’s  LSA  Plan  (Task  102),  alternative 
support  systems  (Task  302),  and  fielding 
analysis  (Task  402).  If  task  results  are 
to  be  delivered  to  the  government,  the 
LSA  program  Statement  of  Work  (SOW) 
must  establish  that  requirement.  The 
applicable  Data  Item  Descriptions  (DIDs) 
must  be  specified  and  delivery  instruc¬ 
tion  cited  on  the  Contract  Data  Re¬ 
quirement0.  List  (CDRL),  DD  Form 
1423.  The  ILS  managers  should  be 
aware  of  the  amount  of  documentation 
that  is  available.  Only  the  LSAR  data 
that  are  required  should  be  ordered  by 
the  joint  program  office.  In  other 
words,  the  ILS  manager  needs  to  deter¬ 


mine  what  data  are  needed,  and  when. 
From  this  determination,  identification 
of  output  reports,  LSAR  data  records, 
and  tasks  required  to  meet  the  needs 
should  be  possible. 

Tailoring  the  LSA/LSAR— 7 

Tailoring  LSA.  The  key  to  a  productive 
and  cost-effective  LSA  program  is 
proper  tailoring  of  the  LSA  subtasks  so 
that  the  available  resources  are  concen¬ 
trated  on  the  tasks  which  will  most 
benefit  the  program.  Limitations  on  ac¬ 
quisition  funding  require  that  the  LSA 
effort  be  applied  selectively  in  order  to 
improve  hardware  design  and  support 
concepts,  not  merely  to  collect  data. 
The  joint  program  ILS  manager  plays  a 
significant  role  in  the  tailoring  process. 
Appendix  A  to  MIL-STD- 1388-1 A  pro¬ 
vides  guidance  in  tailoring  LSA  re¬ 
quirements  to  fit  the  needs  of  a  specific 
program. 

Tailoring  LSAR.  Tailoring  LSAR  data 
is  a  mandatory  requirement  for  acquisi¬ 
tion  programs.  The  tailoring  decisions 
should  be  based  on  (a)  the  LSA  tailoring 
process  described  in  the  preceding  para¬ 
graph,  (b)  related  engineering  and  ILS 
element  analysis  efforts  that  result  in 
LSAR  data,  and  (c)  deliverable  logistics 
products  specified  b'  DIDs  to  be  in¬ 
cluded  in  the  performing  activity  con¬ 
tracts).  In  addition,  LSAR  data  records 
utilization  may  be  broken  down  by 
hardware  level  (system,  subsystem,  low¬ 
est  repairable  assembly,  part, 
tools/TMDE/support  equipment).  Some 
data  records  are  applicable  to  all  hard¬ 
ware  levels,  and  some  are  not  applicable 
to  any  depending  upon  program  re¬ 
quirements.  Appendix  E  to  MIL-STD- 
1388-2A  provides  detailed  guidance  for 
tailoring  the  LSAR. 

It  is  DoD  policy  to  require  contractors, 
under  the  terms  of  their  contracts,  to 
provide  recommendations  for  application 
and  tailoring  of  LSA  tasks  and  LSAR  (as 
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DATA 

SHEET 

RECORD  TITLE 

RELATED 

LSA  TASK  NO. 

A 

Operation  and  Maintenance  Requirements 

205 

B 

Item  Reliability  and  Maintainability 

Characteristics 

205,301 

401.501 

B1 

Failure  Modes  Effects  and  Criticality  Analysis 

301 

B2 

Criticality  and  Maintainability  Analysis 

301 

C 

Operation  and  Maintenance  Task  Summary 

301,401.501 

D 

Operation  and  Maintenance  Task  Analysis 

301.401.501 

D1 

Personnel  and  Support  Requirements 

301.401.501 

E 

Support  Equipment  or  Training  Material 
Description  and  Justification 

401.501 

El 

Unit  Under  Test  |UUT)  and  Automatic 

Program(s) 

401.501 

F 

Facility  Description  and  Justification 

401.501 

G 

Skill  Evaluation  and  Justification 

401.501 

H 

Support  Items  Identification 

401.501 

HI 

Support  Items  Identification 
(Application  Related) 

401,501 

J 

Transportability  Engineering 

Characteristics 

401.501 

Figure  9-1  LSAR  Data  Records/Relationships ^ 


External  Constraints 


well  as  other  LSA  documentation)  re¬ 
quirements  in  one  phase,  for  proposed 
application  to  the  succeeding  phase. 
DoD  policy  also  specifies  that  the  con¬ 
tractor’s  management  system  and  data 
product  formats  shall  be  used,  unless  the 
contractor’s  approaches  cannot  satisfy 
the  program  needs.-^ 

Integrated  Support  Plan  (ISP) 

The  Integrated  Support  Plan  (ISP)  is  a 
contractor-prepared  document  that  de¬ 
tails  the  incorporation  of  ILS  considera¬ 
tions  during  the  design,  development, 
and  proauction  processes  of  system  ac¬ 
quisitions.  This  comprehensive  plan 
should  be  used  as  a  control  and  mea¬ 
suring  device  of  the  offeror’s  intended 
ILS  program  management,  as  well  as  the 
contractor’s  contemplated  compliance 
with  the  specific  ILS  requirements  of 
the  joint  program  as  stated  in  the  Re¬ 
quest  for  Proposal  (RFP). 

ISP  activities  may  also  be  used  to  struc¬ 
ture  ILS  studies  and  other  deliverables 
for  follow-on  logistic  effort.  Pertinent 
portions  of  the  IPS  are  usually  incorpo¬ 
rated  into  updates  of  the  joint  program 
office  prepared  ILSP.  The  ISP  is  an  it¬ 
erative  document  that  must  be  accepted 
and  approved  by  the  Government.  Data 
Item  L-6138  provides  preparation  in¬ 
structions.  The  contents  of  a  contrac¬ 
tor’s  ISP  should  include: 

•  Organization 

•  Responsibilities 

•  Schedules 

a  Major  Tasks 

•  Sub-plans  ( e.g .,  LSA,  training,  pro¬ 
visioning) 

•  Interrelationships  among  logistic 
elements 


• 

•  Other  Pertinent  Factors 
S.O  SUMMARY 

•  All  multiservice  acquisition  pro¬ 
grams  should  use.  and  follow  the  con¬ 
cepts  and  principles  of  ILS  delineated  in 
DoD  Directive  5000.39  and  the  JLC 
joint  directive  -  AR  700-129/  OP- 
NAVINST  4105.2/ AFR  800-43/MCO 
11310,86. 

•  The  overall  objective  of  an  1L£ 
program  is  to  field  supportable  sys¬ 
tems/equipment  in  the  planned  opera¬ 
tional  environments  that  meet  estab¬ 
lished  system/equipment  requirements  or 
System  Readiness  Requirments  at  an 
affordable  Life-Cycle  Cost  (LCC). 

•  The  lead  Service  should  designate 
an  ILS  manager  prior  to  establishing  an 
acquisition  strategy  to  ensure  that  ILS 
considerations  are  properly  included  in 
the  strategy. 

•  The  participating  services  should 
each  designate  an  ILS  representative, 
and  if  possible,  the  representative  should 
be  co-located  with  the  lead  Service  ILS 
manager. 

•  The  ILS  planning  functions  are  es¬ 
sential  to  the  successful  integration  of  an 
equipment  into  operational  use. 

•  Logistics  planning  must  begin  at  the 
initial  program  milestone-program  initi¬ 
ation. 

«  Early  logistics  R&D  is  designed  to 
cost-effectively  influence  equipment 
design. 

»  A  recommended  content  and  format 
for  a  J1LSP  are  described  in  Appendix 
D. 


9/  MILSTD-1369A,  "Integrated  Logistic  Support 
Program  Requirements." 


•  Each  service  has  different  missions, 
operating  concepts,  and  operating  envi¬ 
ronments,  as  do  standard  practices, 
procedures  and  doctrines  for  providing 
logistic  support. 

•  There  are  several  logistics  support 
planning  and  management  tools  to  assist 
the  program  manager  and  staff.  The 
primary  tools  are  listed  below: 

-  The  Integrated  Logistics  Support 
Plan  (ILSP), 

-  The  Logistics  Support  Analysis 
(LSA), 

-  The  Logistics  Support  Analysis 
Record  (LSAR),  and 

-  The  Integrated  Support  Plan 
(ISP). 


1/  "Integrated  Logistics  Support  Guide,"  DSMC, 
May  1986.  p.  17-1. 


2/  DoD  Directive  5000.39,  "Acquisition  and  Man¬ 
agement  of  Integrated  Logistic  Support  for  Systems 
and  Equipment,"  17  November  1983. 


2/  AR  700-129/OPNAVINST  4105.2/AFR  800- 
43/MCQ  11310.86,  "Management  and  Execution  of 
Integrated  Logistic  Support  (ILS)  Programs  for 
Multiservice  Acquisition!!,"  1987. 


4/  MILSTD-1388-1A,  "Logistic  Support  Analy¬ 

sis." 


5/  MILSTD-1358-2A,  "DoD  Requirements  for  a 

Logistic  Support  Analysis  Record." 

6/  “Program  Manager’s  Notebook,"  DSMC,  Oc¬ 
tober  1985.  p.  3.9a 


7/  "Integrated  Logistics  Support  Guide,"  DSMC, 
May  1986.  pp.  2-2  it  2-3, 

8/  "Program  Manager's  Notebook,"  p.  3.9c. 


10/  "Program  Manager1!  Notebook,"  pp.  3.9.1c- 
3.9. Id. 

11/  "Program  Manager'*  Notebook,"  p.  8.9. le. 

12/  DoD  Directive  5000.48,  “Acquisition  Stream¬ 
lining,"  1C  January  1986,  p.  3. 
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CHAPTER  10 

TEST  AND  EVALUATION 


1.0  SYNOPSIS 

Test  and  Evaluation  (T&E)  is  primarily 
concerned  with  making  a  direct  contri¬ 
bution  to  th"  development,  production, 
and  fielding  of  a  system  which  meets 
users’  requirements  in  the  case  of 
muitiservice  acquisition  programs.  In 
addition,  the  demonstration  of  a  system’s 
technical  capability,  operational  effect¬ 
iveness,  and  suitability  are  key  to  the 
release  of  additional  funds  and  to  the 
decision  to  advance  a  development  to 
the  next  phase.  Section  2.0  of  this 
chapter  will  discuss  the  background  of 
T&E,  Section  3.0  will  discuss  inde¬ 
pendent  agencies  and  offices.  Section  4.0 
will  address  Test  and  Evaluation  Master 
Plans  (TEMP),  and  Section  5.0  will 
summarize  the  chapter. 

2.0  BACKGROUND 

DoDD  5000.3,  "Test  and  Evaluation,” 
provides  the  DoD  policy  concerning 
T&E,  establishes  the  responsibilities  of 
OSD  level  T&E  related  offices,  and 
authorizes  the  issuance  of  a  set  of  T&E 
related  manuals  as  follows:^: 

«  DoD  5000.3-M-l,  "Test  and 
Evaluation  Master  Plan  Guidelines." 

•  DoD  5000.3-M-2,  "The  Department 
of  Defense  Foreign  Weapons  Evaluation 
Program." 

•  DoD  5000.3-M-3,  "Software  Test 
and  Evaluation  Manual." 

«  DoD  5000.3-M-4,  "Joint  Test  and 
Evaluation  Procedures  Manual." 

•  DoD  5000.3-M-5,  "Procedures 
Manual  -  Improving  Test  and  Evaluation 
Effectiveness  in  Support  of  the  Major 
Weapon  Systems  Decision  Process." 


The  first  manual  was  issued  8  October 
1986.  The  remaining  documents  are 
currently  in  various  stages  of  dev¬ 
elopment  and  review.  In  addition,  DoD 
5000.3-M-4  will  replace  the  current 
Joint  Procedures  Manual.-^ 

Each  service  has  its  own  T&E  regulation 
which  implements  the  DoD  directive, 
and  amplifies  the  requirement  of  system 
conception-to-fielding  test  and  evalu¬ 
ation. 

The  major  tasks  of  test  and  evaluation 
in  a  system  development  and  acquisition 
program  are  to  assist  in  the  design 
process  of  the  system  and  to  address  the 
areas  of  risk  as  detailed  in  the  DCP  and 
the  program  charter  or  directive.  T&E 
is  conducted  to  demonstrate  feasibility, 
to  minimize  design  risks,  and  to 
determine  the  design  alternatives  anti 
trade-offs  necessary  to  best  achieve 
program  objectives  during  the 
demonstration  and  validation  phase  of 
the  acquisition  process.  During  the 
Full-Scale  Development  (FSD)  phase, 
T&E  progresses  from  component 
through  subsystem  tests,  to  full  system 
tests.  The  objectives  then  are  to  further 
determine  that  design  risks  are 
minimized,  prior  to  the  FSD  phase,  that 
the  system  design  is  complete,  that  the 
system’s  military  utility  will  justify 
production,  and  primarily  to  assess 
compliance  with  system  requirements. 
Although  development  testing  wih 
predominate  T&E  considerations  during 
this  phase,  operational  testing  must  have' 
been  conducted  to  satisfy  the  questions 
concerning  operational  effectiveness  and 
suitability  before  a  decision  can  be  made 
to  enter  the  FSD  phase. 

For  some  time  prior  to  about  1970,  the 
emphasis  in  the  acquisition  of  defense 
systems  was  on  "total  package 
procurement"  -  a  contract  was  let  for  a 
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complete  system  development  and  pro¬ 
curement  program  after  an  initial  paper 
study  and  definition  phase.  The  theory 
was  that  if  a  program  or  system  was 
sufficiently  defined  at  the  outset,  a 
contractor  could  be  expected  to  deliver 
the  required  product  at  a  predetermined 
cost.  The  concept  of  total  package 
procurement  was  not  totally  successful 
for  a  number  of  reasons,  such  as: 
overoptimistic  cost  and  performance  es¬ 
timates,  and  inaccurate  initial  defini¬ 
tions.  The  programs  often  experienced 
large  cost  overruns  and  significant  per¬ 
formance  deficiencies. 

Several  groups  -  the  Blue  Ribbon  De¬ 
fense  Panel,  the  Commission  on  Gov¬ 
ernment  Procurement  and  the  Defense 
Science  Board  -  recognized  the  defi¬ 
ciencies  of  these  practices.  Partly  as  a 
result  of  their  recommendations,  new 
policies  evolved  that  emphasized 
demonstrated  performance  as  the  pacing 
function  for  defense  acquisition  pro¬ 
grams.  The  key  feature  of  the  new 
policies  is  the  periodic  review  of  the 
programs  at  critical  milestones.  During 
these  periodic  reviews  by  the  Joint  Re¬ 
quirements  Oversight  Council  (JROC) 
and  the  Defense  Acquisition  Board 
(DAB)  (for  major  systems),  program 
progress  is  compared  with  program  goals 
and  objectives,  and  a  decision  is  made 
to  continue,  redirect  or  cancel  the  pro¬ 
gram. 

For  such  comparisons  to  be  effective, 
reliable  and  accurate  measurements  of 
program  progress  are  necessary.  Test 
and  evaluation,  the  primary  means  for 
making  such  measurements,  became  the 
cornerstone  of  the  new  acquisition  poli¬ 
cies  and  were  emphasized  in  their  im¬ 
plementation.  In  addition  to  the  two 
primary  offices  within  OSD  concerned 
with  T&E,  the  Director,  Operational 
Test  and  Evaluation  (DOT&E),  and  ihe 
Deputy  Under  Secretary  of  Defense, 
Test  and  Evaluation  DUSD(T&E),  each 
service  established,  or  gave  new  empha¬ 


sis  to,  independent  operational  test 
agencies  and  headquarters  staff  focal 
points  for  conducting  the  required  test 
and  evaluation.  While  the  DUSD(T&E) 
reports  to  the  USD(A),  the  DOT&E  is 
an  independent  element  within  the  OSD. 
In  this  regard,  the  services  publish  an 
annual  memorandum  of  agreement  on 
miltiservice  operational  T&E  and  joint 
T&E.  (See  Appendix  C  for  the  MOA 
published  in  1986.) 

Types  of  Test  and  Evaluation 

The  two  principal  types  of  test  and 
evaluation  conducted  in  the  acquisition 
process  are  Development  Test  and  Eval¬ 
uation  (DT&E),  and  Operational  Test 
and  Evaluation  (QT&E).  DT&E  is  con¬ 
ducted  by  or  under  the  supervision  of 
the  development  agency  to  evaluate 
technical  performance  of  prototype 
equipment.  This  testing  is  generally 
conducted  by  engineers  and  technicians 
-  either  contractor  or  government  -  in 
carefully  controlled  conditions.  OT&E, 
on  the  other  hand,  is  conducted  exclu¬ 
sively  by  military  personnel  to  deter¬ 
mine  the  degree  to  which  new  equip¬ 
ment  fulfills  military  operational  re¬ 
quirements.  It  is,  as  a  rule,  conducted 
under  conditions  that  duplicate,  as 
closely  as  poss:ble,  the  environment  in 
which  the  equipment  is  expected  to 
perform  when  deployed. 

These  assessments  serve  important  func¬ 
tions  in  the  acquisition  process.  DT&E 
assists  in  the  actual  design  and  develop¬ 
ment  of  a  system  in  which  initial  de¬ 
signs  are  converted  to  hardware,  It  is 
an  iterative  process  of  test,  note  defi¬ 
ciencies,  and  fix  deficiencies.  DT  can 
be  used  to  validate  -  providing  the  nec¬ 
essary  feedback  for  an  orderly  progres¬ 
sion  from  initial  design  through  engi¬ 
neering  model  stages  to  production  pro¬ 
totype.  Additionally,  DT&E  provides 
information  on  the  progress  of  new  sys¬ 
tem  development.  The  progress  is  as¬ 
certained  by  comparing  measured  system 
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performance  with  a  set  of  technical 
goals  and  objectives  for  the  program.  A 
principal  contribution  of  DT&E,  espe¬ 
cially  prior  to  Full-Scale  Development 
phase,  is  the  assessment  of  alternative 
system  concepts  and  technical  ap¬ 
proaches.  DT  should  be  oriented  to 
showing  engineering  progress  toward 
resolving  the  operational  issues. 

OT&E,  like  DT&E,  also  provides  essen¬ 
tial  information  for  decision-making  by 
comparing  system  operational  perfor¬ 
mance  with  operational  objectives. 
Generally  speaking,  the  final  phase  of 
an  Initial  Operational  Test  and  Evalua¬ 
tion  (IOT&E)  OPEVAL  is  conducted 
with  one  of  the  Low  Rate  Initial  Pro¬ 
duction  (LRIP)  articles.  If  in  fact  an 
OPEVAL  is  not  conducted  with  a  pro¬ 
duction  representative  test  article,  then  a 
Follow-on  Operational  Test  and  Evalua¬ 
tion  (FOT&E)  is  required. 

Combined  DT&E  and  OT&E  are  often 
conducted,  especially  early  in  the  devel¬ 
opment  of  large,  expensive  systems  or 
systems  which  will  have  a  small  number 
produced  and  fielded.  Table  10-1  illus¬ 
trates  the  services’  T&E  phases  in  rela¬ 
tion  to  acquisition  milestones  and  phases. 

T&E  for  Special  Acquisition  Programs 
includes  the  application  of  DT&E  prin¬ 
ciples  to  systems  which  are  acquired  at  a 
low  rate  over  a  long  period  of  time  such 
as  ships,  space  systems,  and  unique 
platforms.  Software  T&E  is  gaining  in 
importance  as  may  be  noted  from  the 
plan  to  issue  the,  "Software  Test  and 
Evaluation  Manual."  as  cited  above.  The 
testing  aspects  of  software  include  test¬ 
ing  against  mission  objectives,  the  artic¬ 
ulation  of  quantitative  goals  and  thresh¬ 
olds,  and  the  institutionalization  of  an 
approach  to  improve  the  flow  of  infor¬ 
mation  concerning  software  testing 
within  the  military  services  and  OSD. 


3.0  INDEPENDENT  T&E  AGEN¬ 
CIES 

One  of  the  key  recommendations  of  the 
Blue  Ribbon  Defense  Panel  implemented 
by  SECDEF  is  the  policy  requiring  each 
service  to  maintain  a  major  field 
agency,  separate  and  distinct  from  both 
the  developing  or  procuring  activity  and 
the  eventual  user  activity,  to  be  respon¬ 
sible  for  the  conduct  of  OT&E  and  the 
monitoring  of  DT&E.  Each  such  agency 
is  required  to  report  the  results  of  inde¬ 
pendent  OT&E,  normally  by  Indepen¬ 
dent  Evaluation  Reports  (IER),  directly 
to  the  service  chief,  and  to  the  Defense 
Acquisition  Executive  when  appropriate. 
The  services’  independent  OT&E  agen¬ 
cies  are  as  follows: 

-  ARMY-U.S.  Army  Operational  Test 
and  Evaluation  Agency  (OTEA),  5600 
Columbia  Pike,  Falls  Church,  Virginia 
22041; 

-NAVY-Commander  Operational  Test 
and  Evaluation  Force,  (COMOPTEV- 
FOR),  Norfolk,  Virginia  23511; 

-MARINE  CORPS-Marine  Corps  Op¬ 
erational  Test  and  Evaluation  Activity 
(MCOTEA),  Quantico,  Virginia  22134; 
and 

-AIR  FORCE-Air  Force  Operational 
Test  and  Evaluation  Center  (AFOTEC), 
Kirtland  Air  Force  Base,  New  Mexico 
37117. 

The  foregoing  organizations  were  estab¬ 
lished  by  the  services  to  fulfill  the 
"independent  OT&E"  requirements  of 
DoD  policy.  Each  service  has  other  ac¬ 
tivities  tha  perform  testing  functions, 
generally  within  its  development  and  ac¬ 
quisition  structure.  These  activities  are 
configured  and  staffed  to  conduct  tech¬ 
nical,  development,  and  test  evaluations. 
These  activities  are  normally  specified 
for  particular  test  support  in  a  program’s 
charter  or  charter-implementing  docu- 
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TABLE  10-1  TEST  AND  EVALUATION  PHASES 


ACQUISITION 

MILESTONE  0  ■  II  III 


ACQUISITION 

PHASE 

CONCEPTUAL 

DEMONSTRATION 
&  VALIDATION 

FULL-SCALE 

DEVELOPMENT 

PRODUCTION 

&DEPLOYMENT 

ARMY  T&E 

DT&E 

OT&E 

TFT 

CEP 

DT 

EUTE 

PPT 

IQT 

PQT.  FPT 

FOT 

NAVY  T&E 

DT&E 

OT&E 

NOT  CATEGORIZED 

NOT  CATEGORIZED 

DT  1 

OT  1 

DT  II 

OT  II  (NOE) 

TECH  EVAL 

OPEVAL 
(FINAL  OT  II) 

DT  III 

FOT&E/(OT  III,  OT  IV) 

AIR  FORCE  T&E 

OT&E 

OT&E 

•FOT&E 1 

FOT&E  II 

NOTES: 

1 .  TFT:  ARMY  -  TECHNICAL  FEASIBILITY  TEST 

2.  CEP:  ARMY  -  CONCEPT  EVALUATION  PROGRAM 

3.  DT:  ARMY  -  DEVELOPMENT  TEST 

4.  EUTE:  ARMY  -  EARLY  USER  TEST  AND  EXPERIMENTATION 

6.  PPT:  ARMY  -  PRODUCTION  PROVE  TEST 

6.  IOT:  ARMY  -  INITIAL  OPERATIONAL  TEST 

7.  PQT:  ARMY  -  PRODUCTION  QUALIFICATION  TEST 

8.  FPT:  ARMY  -  FOLLOW-ON  PRODUCTION  TEST 

9.  FOT:  ARft  Y  —  FOLLOW-ON  OPERATIONAL  TEST 

10.  FOT&E:  NAVY  -  FOLLOW-ON  OPERATIONAL  T&E 

1 1 .  NOE:  NAVY  —  NAVY  OPERATIONAL  EVALUATION  (OPEVAL) 

12.  FOT&E  I:  AIR  FORCE  -  FOLLOW-ON  OPERATIONAL  T&E  I 

13.  FOT&E  II:  AIR  FORCE  -  FOLLOW-ON  OPERATIONAL  T&E  II 
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mentation  ( e.g .,  the  Test  and  Evaluation 
Master  Plan  [TEMP])  to  provide  test 
and/or  evaluation  support  either  inde¬ 
pendently  or  as  monitor  agency  for 
contractor  DT&E  efforts. 

The  Department  of  Defense’s  Office  of 
Operational  Test  and  Evaluation  (OT&E) 
has  established  a  Defense  Test  and  Eval¬ 
uation  Council  that  will  review  the  test 
resources  requirements  of  the  military 
services  and  make  recommendations  to 
avoid  duplication  of  efforts  and  to  use 
test  assets  more  efficiently. 

In  1978,  the  Joint  Logistics  Commanders 
(JLC)  established  a  Test  and  Evaluation 
Planning  Guidance  Ad  Hoc  Group  which 
was  subsequently  dissolved  after  its  task 
was  completed.  Its  assigned  task  was  to 
"assess  the  joint  testing  environment  as 
it  existed  in  the  late  1970s,  determine 
the  best  approach  to  resolve  deficiencies 
in  existing  directives,  and  develop  ap¬ 
propriate  policy  and  guidance  for 
greater  commonality  of  test  and  evalua¬ 
tion  effort."  Since  the  JLC  a^e  individ¬ 
ually  the  service  material  development 
and  logistics  commanders,  and  since  the 
membership  of  the  Ad  Hoc  Group  rep¬ 
resented  development  T&E  interests,  the 
group’s  implicit  focus  was  on  DT&E. 
The  group  conducted  a  thorough  review 
of  T&E  regulations  and,  with  the  assis¬ 
tance  of  its  OT&E  counterparts,  polled 
test  managers  of  over  twenty  joint  pro¬ 
grams. 

Some  of  the  direct  results  of  the  T&E 
Ad  Hoc  Group’s  work  are  in  evidence. 
Changes  to  service  regulations  were  ini¬ 
tiated  which  required  joint  program 
testing  to  be  performed  in  accordance 
with  the  directives  of  the  executive  ser¬ 
vice,  consistent  with  JLC’s  Multiservice 
Program  Management  Directive.  A 
Compendium  of  Test  Terminology  was 
compiled,  published,  and  made  available 
to  the  T&E  community.^  Every  joint 
program  manager  and  multiservice  T&E 


director  will  still  find  the  compendium 
invaluable. 

Subsequently,  a  multiservice  DT&E 
Commanders’  Conference  recommended 
that  an  Ad  Hoc  Group  be  established  as 
a  permanent  joint  acquisition  DT&E  in¬ 
terface  and  focal  point  with  the  JLC. 
That  recommendation  was  implemented 
by  the  issuance  of  a  joint  regulation 
which  requires  semi-annual  meetings  of 
the  Group,  undertaking  of  items  rec¬ 
ommended  by  the  recurring  Multiservice 
DT&E  commander's  Conference,  annual 
reviev'  of  the  Compendium  of  Terms 
and  coordination  with  the  OT&E  com¬ 
munity  on  appropriate  issues. 

The  joint  program  manager  and  his  test 
organization  should  take  advantage  of 
the  continuing  work  done  by  the  Group, 
whose  members  are: 


Air  Force 

-  HQ  AFSC/TEVP  (Office  of  primary 
responsibility  for  convening  meetings) 

Andrews  AFB 

Washington,  D.C.  20334-5000 

-  HQ  AFLC/MMA 
Wright-Patterson  AFB 
Ohio  45433-5001 

Army 

-  HQAMC/AMCQA-ST 
5001  Eisenhower  Avenue 
Alexandria,  Virginia  22333-0001 

-  TECOM/DRSTE-TO-P 
Aberdeen  Proving  Ground 
Aberdeen,  Maryland  21005-5055 

Navy 

-  CNO  (OP-04) 

Washington,  D.C.  20350-2000 

NAVAIR  (AIR-01) 

Washington,  D.C.  20361-1000 

Marine  Corps 
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-  Director,  Development  Center 

D050-3 

MCDEC 

Quantico,  Virginia  22134-5000 

Coincidental  to  this  work  towards  com¬ 
monality  in  development  T&E,  the 
OT&E  Commanders,  who  currently  meet 
to  discuss  mutual  issues  on  a  quarterly 
basis,  appointed  an  Ad  Hoc  Group  for 
Joint  Service  Testing  in  July  1978.  This 
Group  is  producing  an  annual  Memo¬ 
randum  of  Agreement  on  Multiservice 
OT&E  and  Joint  T&E,  as  cited  in  sec¬ 
tion  2.0  of  this  chapter,  and  intends  to 
expand  the  agreements,  as  well  as  ad¬ 
dress  other  areas  highlighted  by  the 
OT&E  Commanders. 

In  1979  the  Joint  Logistics  Commanders 
promulgated  guidance  entitled,  "Joint 
Service  Interface  on  Development  Test 
and  Evaluation  (DT&E).'-^  This  guid¬ 
ance  provides  for  regular  meetings  to  be 
held  at  least  every  six  months  wherein 
potential  DT&E  issues  will  be  discussed. 

There  is  great  potential  for  misunder¬ 
standing  the  multiservice  environment 
because  common  or  nearly  common 
terms  do  not  always  have  the  same 
meaning  in  the  different  services.  For 
example,  consider  the  (deceptively)  sim¬ 
ple  word  "initial."  When  included  in  a 
phrase  that  has  wide  application  and  un¬ 
derstanding  such  as  Initial  Operational 
Capability  (IOC),  the  Joint  Dictionary 
meaning  prevails,  and  mutual  under¬ 
standing  is  facilitated.  But  unique  ap¬ 
plication  of  the  word  in  another,  single¬ 
service  environment  may  give  rise  to 
misunderstanding.  For  example,  the 
Navy  and  Air  Force  describe  IOTE  as 
an  activity  that  can  occur  in  the 
Demonstration  &  Validation  and  Full 
Scale  Development  Phases  while  the 
Army  conducts  Initial  Operational  Test 
in  the  Full  Scale  Development  Phase 
only. 


numi  a  itj  M-fi  a 


\  v  m*  v  ~^»  vs* 


As  a  rule,  particular  communities 
throughout  the  services  are  aware  of 
service-peculiar  practices.  Activities 
which  cut  across  service  borders,  such  as 
those  undertaken  by  professional  soci¬ 
eties  and  the  Joint  Logistics  Comman¬ 
ders  have  promoted  wider  understanding 
of  service-peculiar  concepts  and  termi¬ 
nology  by  members  of  specific  disci¬ 
plines  such  as  financial  managers  and 
logisticians.  Of  course,  these  disciplines 
occasionally  develop  phr-.reology  whose 
shades  of  meaning  are  understood  within 
the  community,  but  not  outside,  irre¬ 
spective  of  service  association.  The  op¬ 
erational  testing  community,  for  in¬ 
stance,  has  found  it  necessary  to  make  a 
specific  distinction  between  "joint  test¬ 
ing"  and  "multi-service"  testing,  The 
commanders  of  the  ser  ices’  independent 
operational  test  organizations  have 
agreed  that  "joint  T&E"  means  an  OSD 
sponsored  T&E  program  structured  to 
evaluate  system  operational  or  technical 
performance  under  realistic  conditions 
with  two  or  more  services  participating 
or  with  interrelated/interacting  systems" 
for  the  purpose  of  providing  informa¬ 
tion  required  by  Congress,  OSD,  Com¬ 
manders  of  Unified  and  Specified 
Commands,  or  DoD  components. 
"Multiservice  OT&E"  means  "OT&E 
conducted  jointly  by  two  or  more  ser¬ 
vices  for  systems  to  be  acquired  by  more 
than  one  service,  or  for  a  service’s  sys¬ 
tems  which  have  interfaces  with  equip¬ 
ment  of  another  service."  This  distinc¬ 
tion  was  made  to  allow  the  service  test 
organizations  to  differentiate  between 
their  acquisition-oriented  test  activity 
and  that  mandated  by  Department  of 
Defense  Directive  5000.3  under  the  di¬ 
rection  of  the  Director,  Operational  Test 
and  Evaluation  (DOT&E).  Thus,  the 
manager  of  a  joint  service  acquisition 
program  will  probably  be  advised  that 
"multiservice"  rather  than  "joint  testing" 
must  be  accomplished  to  fulfill  the  pro¬ 
gram’s  requirements. 
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4.0  TEST  AND  EVALUATION 
MASTER  PLAN 

The  Test  and  Evaluation  Master 
Plan  (TEMP)  required  by  Department  of 
Defense  Directr've  5000.3  is  recognized 
throughout  the  test  community  as  the 
controlling  management  document  for 
identification  and  integration  of  all  ob¬ 
jectives,  responsibilties,  resources,  and 
schedules  for  all  aspects  of  T&E. 

The  TEMP  is  a  formal  and  .v.-and- 
alonc  document.  Department  of  Defense 
Directive  5000.3  includes  guidelines  for 
the  content  and  format  of  TEMPs.  DoD 
5000.3-M-l,  "Test  and  Evaluation  Mas¬ 
ter  Plan  Guidelines,"  provides  expanded 
TEMP  guidance.  Briefly,  the  TEMP,  or 
combination  of  TEMP  supporting  docu¬ 
ments  (System  Test  Plan  [STP],  and  Pro¬ 
gram  Introduction  Document  [PID]  -  Air 
Force,  Outline  Test  Plan  [OTP],  and  Test 
Design  Plan  [TDP-Army])  must  contain: 

-  System  description  and  intended 
operational  mission, 

-  Critical  T&E  issues, 

-  Test  objectives,  and 

-  Required  technical  and  operational 
characteristics,  goals,  and  thresholds. 

-  Integrated  schedule  including  con¬ 
tracting  demonstrations,  technical  eval¬ 
uations  (Navy),  Qualification  OT&E  (Air 
Force),  in-process  review  (Army,  less- 
than-ntajor  systems),  type  classification 
(Army),  approval  for  limited  and/or  full 
product-,  i  (Navy),  as  well  as  required 
"standard1  development  and  operational 
T&E  and  program  milestones. 

-  T&E  resources  required,  including 
laboratory,  ranges,  test  sites,  instrumen¬ 
tation,  major  command  or  fleet  (Navy) 
support  needs,  personnel,  personnel 
training,  logistic  support,  and  funding 


by  program  element  and  appropriation 
per  fiscal  year. 

For  major  acquisition  programs,  OSD 
approval  of  the  TEMP  is  a  requirement 
for  Milestone  I  and  all  subsequent  mile¬ 
stones.  Clearly  the  TEMP,  like  the  Pro¬ 
gram  Management  Plan  (or  Joint  Devel¬ 
opment  Plan)  which  it  supports,  as  well 
as  the  Integrated  Logistics  Support  Plan, 
must  be  started  early.  The  Test  Division 
(Directorate  or  Joint  Test  Office),  of  the 
joint  program  office  must  work  in  close 
cooperation  with  the  lead  service  orga¬ 
nizations  responsible  for  DT&E  and 
OT&E,  as  specified  earlier  in  this  chap¬ 
ter.  These  organizations  must  integrate 
test  and  evaluation  requirements  of  the 
specific  program  with  those  of  other 
programs. 

Service  T&E  directives  specify  that  its 
T&E  regulations  will  be  followed  for 
multiservice  testing  for  which  it  is  the 
lead  service  ( e.g .,  OPNAVINST 
3960.  lOB-^  states  that  when  the  Navy  is 
lead  service  in  a  multiservice  acquisition 
program,  multiservice  T&E  will  be  con¬ 
ducted  as  outlined  in  the  instruction. 
Further,  tests  conducted  by  a  single  ser¬ 
vice  will  be  conducted  under  its  own 
regulations.  OT&E  for  multiservice 
programs  should  be  planned,  conducted, 
and  reported  by  each  service’s  indepen¬ 
dent  OT&E  agency;  however,  close  co¬ 
operation  between  these  agencies  and 
detailed  integration  of  OT&E  plans 
should  be  achieved  to  minimize  duplica¬ 
tion. 

The  joint  program  manager  should  ex¬ 
pect  the  lest  manager  of  the  joint  pro¬ 
gram  office  to  promote  specific  testing 
by  a  single,  consolidated  -  that  is,  with 
all  interested  services  participating  -  test 
group  whose  reports  would  be  available 
to  service  agencies  for  independent 
evaluations.  (The  procedure  of  "joint 
testing  and  independent  evaluation"  was 
a  specific  recommendation  of  the  De¬ 
fense  Science  Board’s  Acquisition  Cycle 
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Task  Force.)  Championing  that  cause 
might  be  one  of  the  most  significant  acts 
a  joint  program  manager  can  perform  to 
prevent  proliferation  of  separate  service 
testing  from  slowing  the  PM’s  program. 

5.0  SUMMARY 

•  Successful  accomplishment  of  Test 
and  Evaluation  (T&E)  objectives  is  a 
key  requirement  for  decisions  to  commit 
significant  additional  resources  to  a  pro¬ 
gram,  or  to  move  from  one  acquisition 
phase  to  the  next.  T&E  assists  in  the 
resolution  of  Critical  Operational  Issues 
that  are  identified  in  the  DCP  or  other 
applicable  service  requirement  docu¬ 
ments. 

•  There  are  two  principal  types  of 
T&E  conducted  in  the  acquisition  pro¬ 
cess:  Development  T&E  (DT&E)  and 
Operational  T&E  (OT&E). 

•  DT&E  is  conducted  by  or  under  the 
supervision  of  the  development  agency 
to  evaluate  the  technical  performance  of 
prototype  equipment.  Usually  con¬ 
ducted  by  engineers  and  technicians, 
either  contractor  or  government,  under 
carefully  controlled  conditions. 

•  OT&E  is  conducted  exclusively  by 
military  personnel  to  determine  the  de¬ 
gree  to  which  the  new  equipment  will 
fulfill  military  operational  effectiveness 
and  operational  suitability,  including 
supportability,  as  well  as  the  need  for 
any  modifications.  Usually  conducted 
under  conditions  that  duplicate,  as 
closely  as  possible,  the  environment  in 
which  the  equipment  is  expected  to 
perform  when  deployed. 

•  The  services  publish  an  annual 
MOA  on  multiservice  operational  T&E 
and  joint  T&E.  (See  Appendix  C) 

•  Each  of  the  services  has  indepen¬ 
dent  OT&E  agencies  that  are  identified 
in  section  3.0  of  this  chapter. 


«  DoD’s  office  of  OT&E  has  estab¬ 
lished  a  Defense  Test  and  Evaluation 
Council  to  review  the  test  i?sources  of 
the  military  services  and  make  recom¬ 
mendations  to  avoid  dupiicat'.on  of  ef¬ 
forts  and  to  use  test  assets  mere  effi¬ 
ciently. 

•  /  Compendium  of  Test  Terminology 
is  available  to  assist  in  clarifying  redun¬ 
dant  test  terminology. 

•  The  TEMP,  as  specified  by  DoDD 
5000.3,  is  the  controlling  management 
document  for  identification  and  integra¬ 
tion  of  all  objectives,  responsibilities, 
resources,  and  schedules  for  all  aspects 
of  T&E. 

•  Service  T&E  directives  provide 
guidance  to  be  followed  for  multiservice 
testing  for  which  it  is  the  lead  service. 

REFERENCES  AND  FOOTNOTES: 

1/  DoDD  1000.3,  "Te»t  and  Evaluation,"  March 
1986. 

i,l  “Joint  Te»t  and  Evaluation  Procedure*  Man¬ 
ual,"  September  1980. 

2/  Compendium  of  Te»t  Terminology.  December 
1S?8,  compiled  by  the  Joint  Logittic  Commander*’ 
Ad  Hoc  group  on  te*t  and  evaluation  planning  guid¬ 
ance. 

1/  AFSC/AFLC  Regulation  80-24/DARCOM 
REGULATION  70-6</DCO  5000.2,  "Joint  Service* 
Interlace  on  Development  Te»t  and  Evaluation," 
May  1979. 

£/  OPNAV1NST  3960. 10B,  "Te»t  and  Evalua¬ 
tion." 
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CHAPTER  11 
SECURITY 


1.0  SYNOPSIS 

Security  covers  both  classified  and  un¬ 
classified  facilities,  system  hardware  and 
software,  and  also  documentation,  that 
requires  protection  and  special  handling 
procedures.  Unclassified  technical  soft¬ 
ware  or  hardware  rri?y  be  subject  to  re¬ 
striction  in  terms  of  distribution  based 
upon  such  reasons  as  "Foreign  Informa¬ 
tion,"  "Proprietary  Equipment  or  Data," 
or  "Test  and  Evaluation."  OSD  has  is¬ 
sued  DoD  Directive  5200.1,  "DoD  In¬ 
formation  Security  Program,"-7  DoD 
Directive  5200.8,  "Security  (  of  Military 
Installations  and  Resources,"-7  and  DoD 
Directive  5230.24,  "Distribution  State¬ 
ment  on  Technical  Documents,'-7  as 
guid  ce  in  this  area.  Section  2.0  of 
this  chapter  discusses  the  development 
and  application  of  security  classification 
guides  by  the  joint  program  office,  sec¬ 
tion  3.0  addresses  the  control  and  secu¬ 
rity  of  unclassified  technical  software 
and  hardware,  and  business  information 
and  data.  Section  4.0  discusses  system 
security  engineering  management,  and 
section  5.0  summarizes  the  chapter. 

2.0  SECURITY  CLASSIFICATION 
GUIDES 

The  DoD  Information  Security  Program 
(ISP)  is  outlined  in  DoD  Directive 
5200.1  and  supported  by  a  series  of 
handbooks,  including: 

•  DoD  5200. 1-H,  "Department  of 
Defense  Handbook  for  Writing  Security 
Classification  Guidance,"  March  1986. 

•  DoD  5200.1-1,  "Index  of  Security 
Classification  Guides,"  July  1983. 

•  DoD  5200.1 -PH,  "A  Guide  to 
Marking  Classified  Documents,"  Novem¬ 
ber  1982. 


•  DoD  5200.1 -PH-1,  "Classified  In¬ 
formation  Nondisclosure  Agieement," 
July  1985. 

•  DoD  5200. 1 -R,  "Information  Secu¬ 
rity  Program  Regulation,"  June  1986. 

These  handbooks  support  the  DoD  pol¬ 
icy  with  reference  to  information  secu¬ 
rity  which  is: 

",  .  .  to  assure  that  information  that  warrants  pro¬ 
tection  against  unauthorised  disclosure  is  properly 
classified  and  safeguarded  as  well  as  to  facilitate  the 
flow  of  unclassified  information  about  DoD  opera- 

47 

tions  to  the  public.”-' 

•  In  addition,  there  are  a  number  of 
classified  DoD  Directives  5200  series 
that  cover  security  of  systems.  (See 
DoD  5025.1-I.)-7 

The  charter  for  a  joint  program  should 
include  a  discussion  of  the  security  pro¬ 
gram,  the  responsibility  for  issuance  of 
security  guidance  and  the  identification 
of  the  command  or  office  which  will 
provide  security  assistance  to  the  pro¬ 
gram  as  required.  The  Security  Guide 
for  the  program  must  be  developed  early 
in  the  program  and  ideally  prior  to  ini¬ 
tial  funding. 

The  guide  itself  should  be  structured  in 
such  a  manner  that  it  provides  the 
clearest  guidance  possible,  and  be  in  a 
form  that  encourages  use  and  review. 
The  Program  Manager’s  Notebook,  Fact 
Sheet  No.  7.6  discusses  the  development 
of  Security  Guides.-7  The  points  pre¬ 
sented  below  are  summarized  from  the 
Fact  Sheet. 

•  The  guide  should  be  prepared  by  an 
individual  in  the  program  who  is  well 
versed  in  the  overall  acquisition.  When 
planning  a  joint  program,  this  will  in¬ 
volve  close  coordination  with  techni- 


cal/management  personnel  from  each 
participating  service. 

d  The  wording  of  the  guide  must  be 
as  clear  and  unambiguous  as  possible  so 
as  to  minimize  any  possible  misunder¬ 
standing  which  could  lead  to  the  com¬ 
promise  of  classified  equipment,  tech¬ 
nology,  software  or  information.  Pro¬ 
gram  peculiar  phrases  and  acronyms 
should  be  used  only  when  absolutely 
necessary. 

•  The  format  of  the  guide  should  re¬ 
flect  the  best  qualities  of  service  for¬ 
mats.  As  stated  above,  the  guide  should 
encourage  use  by  being  logically  devel¬ 
oped  and  indexed,  with  sufficient  exam¬ 
ples  to  provide  for  a  wide  range  of  ap¬ 
plications. 

•  The  development  of  a  security 
guide  should  follow  a  certain  sequence 
of  steps  which  will  assist  in  its  prepara¬ 
tion.  DoD  Handbook  5200. l-H-^  pro¬ 
vides  detailed  guidance,  expanding  on 
the  steps  cited  below: 

Sten  i  -  Ensure  that  current  guidance 
for  related  programs  or  systems  is  re¬ 
viewed  and  any  generic  guidance  is 
consulted. 

Step  2  -  Review  the  state  of  the  art  of 
the  technology,  including  discussions 
with  the  supporting  Foreign  Intelligence 
Office. 

Step  3  -  Identify  those  factors  which 
give  an  advantage  to  the  United  States 
in  terms  of  capabilities,  exclusive 
knowledge,  manufacturing,  etc. 

Step  4  -  Make  an  initial  classification 
determination. 

Sten  5  -  Identify  specific  items  of  soft¬ 
ware  and  hardware  that  require  classi¬ 
fication. 


Sten  6  -  Determine  how  long  the  classi¬ 
fication  must  last.  This  includes  down¬ 
grading  and  declassification. 

Sten  7  -  The  actual  writing  of  the 
guide. 

•  The  guide  should  be  approved  by 
the  official  who  can  originally  classify 
at  the  highest  level,  and  has  supervisory 
responsibility  for  the  information. 

The  development  and  application  of  a 
well  written  security  guide  will  not  only 
assist  in  the  protection  of  security  in¬ 
formation,  but  also  provide  a  solid 
foundation  for  formalizing  information 
handling  and  disposition. 

3.0  CONTROL  OF  TECHNICAL 
INFORMATION 

Technical  information  which  is  devel¬ 
oped  by  the  Department  of  Defense  of¬ 
ten  requires  limitations  on  dissemination 
for  a  variety  of  reasons  including  the 
results  of  test  and  evaluations,  foreign 
information,  etc.  The  joint  program 
manager  and  technical  and  administra¬ 
tive  staff  personnel  must  be  aware  of 
when  and  why  to  restrict  technical  in¬ 
formation,  and  to  take  such  actions  that 
will  support  the  policies  promulgated  in 
DoD  Directive  5230.24,  "Distribution 
Statement  on  Technical  Documents.'-/ 
All  technical  documentation  generated 
within  the  program  must  be  assigned 
appropriate  distribution  codes,  and  tech¬ 
nical  documents,  including  informal 
working  papers  and  memoranda  which 
are  not  in  the  public  domain  but  may  be 
released  outside  DoD  must  also  include 
distribution  statements.  There  are  seven 
(7)  distribution  statements  currently  ap¬ 
proved  for  technical  documents.  These 
seven  distribution  statements  and  their 
reasons  for  use  are  found  in  Enclosure 
(3)  to  DoD  Directive  5230.24,  and  are 
summarized  below: 
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DISTRIBUTION  5iTATF.MF.NT  A  - 
Approved  for  public  release;  distribution 
is  unlimited. 

•  Only  for  unclassified  technical  data 
cleared  in  accordance  with  DoD  Direc¬ 
tive  5230  9,  "Clearance  of  DoD  Infor¬ 
mation  for  Public  Release."-'1 

•  Documents  with  this  statement  may 
be  sold  and  exported. 

DISTRIBUTION  STATEMENT  B  - 
Distribution  authorized  to  U.S.  Govern¬ 
ment  agencies  only  (fill  in  reason)  (date 
of  determination).  Other  requests  for 
this  document  shall  be  referred  to  (insert 
controlling  DoD  office). 

•  This  statement  may  be  used  on  un¬ 
classified  or  classified  technical  docu¬ 
ments. 

•  Reasons  for  assigning  distribution 
statement  B  includes: 

•  Foreign  Government  Information  - 
To  protect  and  limit  distribution. 

•  Proprietary  Information  -  To  pro¬ 
tect  information  not  owned  by  the  U.S. 
Government  by  a  contractor’s  "limiteo 
rights"  statement,  or  received  with  the 
understanding  that  it  not  be  routinely 
transmitted  outside  the  U.S.  Govern¬ 
ment. 

•  Test  and  Evaluation  -  To  protect 
results  of  test  and  evaluation  of  com¬ 
mercial  products  or  military  hardware 
when  such  disclosure  may  cause  unfair 
advantage  or  disadvantage  to  the  manu¬ 
facturer  of  the  product. 

•  Contractor  Performance  Evaluation  - 
To  protect  information  in  management 
reviews,  records,  of  contract  perfor¬ 
mance  evaluation,  or  other  advisory 
documents  evaluating  programs  of  con¬ 
tractors. 


•  Administrative  or  Operational  Use  - 
To  protect  technical  or  operational  data 
or  information  from  automatic  dissemi¬ 
nation  under  the  International  Exchange 
Program  or  by  other  means. 

c  Software  Documentation  -  Re¬ 
leasable  only  in  accordance  with  the 
provisions  of  DoD  Instruction  7930.2, 
"ADP  Software  Exchange  and  Re¬ 
lease."^ 

«  Specific  Authority  -  To  protect  in¬ 
formation  not  specifically  included  in 
the  above  reasons  and  discussions,  but 
which  requires  protection  in  accordance 
with  valid  documented  authority  such  as 
Executive  Orders,  classification  guide¬ 
lines,  DoD  or  DoD  Component  regula¬ 
tory  documents. 

DISTRIBUTION  STATEMENT  C  - 
Distribution  authorized  to  U.S.  Govern¬ 
ment  agencies  and  their  contractors  (fill 
in  reason)(date  of  determination).  Other 
requests  for  this  document  shall  be  re¬ 
ferred  to  (insert  controlling  DoD  office). 

•  May  be  used  on  unclassified  tech¬ 
nical  documents  or  on  classified  techni¬ 
cal  documents. 

•  Reasons  for  assigning  distribution 
statement  C  include: 

•  Critical  Technology  -  To  protect 
information  and  technical  data  that  ad¬ 
vance  current  technology  or  describe 
new  technology  in  an  area  of  significant 
or  potentially  significant  military  appli¬ 
cation  or  that  relate  to  a  specific  mili¬ 
tary  deficiency  of  a  potential  adversary. 

t  Administrative  or  Operational  Use  - 
Same  as  distribution  statement  B. 

•  Specific  Authority  -  Same  as  distri¬ 
bution  statement  B. 

DISTRIBUTION  STATEMENT  D  - 
Distribution  authorized  to  the  Depart- 
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ment  of  Defense  and  DoD  contractors 
only  (fill  in  reason)(date  of  determina¬ 
tion).  Other  requests  shall  be  referred 
to  (insert  controlling  DoD  office), 

•  May  be  used  on  unclassified  tech¬ 
nical  documents  or  on  classified  techni¬ 
cal  documents. 

•  Reasons  for  assigning  distribution 
statement  D  include: 


e  Premature  Dissemination  -  Same  as 
distribution  statement  D. 

•  Software  Documentation  -  Same  as 
distribution  statement  B. 

«  Critical  Technology  -  Same  as  dis¬ 
tribution  statement  C. 

•  Specific  Authority  -  Same  as  distri¬ 
bution  statement  B. 


c  Premature  Dissemination  -  To  pro¬ 
tect  information  on  systems  or  hardware 
in  the  developmental  or  conceptual  stage 
to  prevent  premature  dissemination. 

•  Software  Technology  -  Same  as 
distribution  statement  B. 

•  Critical  Technology  -  Same  as  dis¬ 
tribution  statement  C. 

•  Specific  Authority  -  Same  as  distri¬ 
bution  statement  B. 

DISTRIBUTION  STATEMENT  E  -Dis¬ 
tribution  authorized  to  DoD  Components 
only  (fill  in  reason)(date  of  determina¬ 
tion).  Other  requests  shall  be  referred 
to  (insert  controlling  DoD  office). 

•  May  be  used  on  unclassified  tech¬ 
nical  documents  or  on  classified  techni¬ 
cal  documents. 

•  Reasons  for  assigning  distribution 
statement  E  include: 

•  Export  Limitations  -  Document 
contains  export-controlled  technical  data 
which  lias  been  designated  by  competent 
authority  in  accordance  with  DoD  Di¬ 
rective  5230.25,  "Withholding  of  Un¬ 
classified  Technical  Data  from  Public 
Disclosure. 

•  Foreign  Government  Information  - 
Same  as  distribution  statement  B, 


DISTRIBUTION  STATEMENT  F  - 
Further  dissemination  only  as  directed 
by  (insert  controlling  DoD  office)(date 
of  determination)  or  higher  DoD  au¬ 
thority. 

•  Normally  used  only  on  classified 
technical  documents,  but  may  be  used 
on  unclassified  technical  documents 
when  specific  authority  exists. 

•  Distribution  statement  F  is  used 
when  the  DoD  originator  determines 
that  information  is  subject  to  special 
dissemination  limitation  specified  by 
paragraph  4-505,  DoD  5200. 1-R, 
"Information  Security  Program  Regula¬ 
tion."^ 

•  When  a  classified  document  assigned 
distribution  statement  F  is  declassified, 
the  statement  shall  be  retained  until  the 
controlling  DoD  office  assigns  the 
proper  distribution  statement  from  this 
Directive. 

DISTRIBUTION  STATEMENT  X  - 
Distribution  authorized  to  U.S.  Govern¬ 
ment  agencies  and  private  individuals  or 
enterprises  eligible  to  obtain  export- 
controlled  technical  data  in  accordance 
with  regulations  implementing  10  U.S.C. 
140c  (date  of  determination).  Other  re¬ 
quests  must  be  referred  to  (insert  con¬ 
trolling  DoD  office,) 

•  This  statement  shall  be  used  on  un¬ 
classified  documents  when  distrubtion 
statements  B,  C,  D,  E,  or  F  are  not  ap- 
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plicable,  but  the  document  does  contain 
technical  data  as  explained  in  DoD  Di¬ 
rective  5230.25  cited  above. 

•  This  statement  shall  not  be  used  on 
classified  technical  documents;  however, 
it  may  be  assigned  to  technical  docu¬ 
ments  that  formerly  were  classified. 

The  selection  of  the  distribution  state¬ 
ment  to  be  used  must  be  thoroughly  re¬ 
viewed  and  then  implemented  so  as  to 
ensure  that  there  are  proper  physical 
controls  to  accomplish  the  intent.  In  to¬ 
day’s  highly  competitive  defense  arena  it 
is  even  more  important  to  properly  and 
equitably  control  the  release  of  technical 
data. 

4.0  SYSTEM  SECURITY  ENGI¬ 
NEERING  MANAGEMENT 

The  System  Security  Engineering  (SSE) 
Management  Program  has  been  devel¬ 
oped  and  implemented  by  the  Air  Force 
and  is  suggested  for  use  by  joint  pro¬ 
gram  offices.  Detailed  procedures  are 
presented  in  AFSCP  207-1,—/  and 
should  be  modified  to  meet  the  needs  of 
a  joint  program  office.  An  overview  of 
the  SSE  Management  Program  is  pre¬ 
sented  below: 

Background.  In  the  past,  communica¬ 
tions  security  was  only  applied  to  devel¬ 
opment  systems  and  absorbed  in  C3 
subsystem  development;  physical  secu¬ 
rity  was  applied  to  nuclear  weapons  or 
was  dealt  with  during  deployment  and 
administratively  treated  as  a  nuclear 
safety  problem;  and  operational  security 
and  information  security  were  often 
deferred  to  deployment.  Some  systems 
were  developed  without  adopting  a  good 
security  program  in  the  very  beginning 
of  the  system’s  development.  It  was  be¬ 
lieved  that  potential  security  vulnerabil¬ 
ity  would  be  addressed  by  attaching  ex¬ 
ternal  equipment,  implementing  admin¬ 
istrative  procedures,  or  adding  security 
personnel  when  the  system  was  de¬ 


ployed.  Recently,  the  threat,  such  as 
human  intelligence  (HUMINT),  signal 
intelligence  (SIGINT),  transnational  ter¬ 
rorism,  and  unconventional  warfare  and 
the  new  modes  of  deployment  and  dis¬ 
persal;  that  is,  tactical  nuclear  forces, 
have  caused  security  issues  to  become 
critical  during  acquisition  decisionmak¬ 
ing.  SSE  has  become  a  formal  discipline 
and  ensures  that  security  is  addressed  at 
the  time  the  design  for  the  system  is 
being  conceptualized  and  throughout  all 
the  phases  of  the  system  acquisition. 

The  SSE  Management  Program.  The 
procedures  of  the  program  define  the 
methods  and  actions  needed  to  deter¬ 
mine  system  or  equipment  vulnerability 
to  ground-initiated  overt  or  covert  at¬ 
tacks  by  an  adversary.  It  also  firmly 
establishes  life  cycle  physical  security  in 
weapon  and  Command,  Control,  Com¬ 
munications,  and  Intelligence  (C3I)  sys¬ 
tems  as  a  condition  of  applying  engi¬ 
neering  and  design  principles  and  devel¬ 
oping  required  countermeasures  and 
procedures. 

SSE  Management  Program  Objectives. 
The  following  are  the  major  objectives 
of  the  program: 

•  Provides  to  the  acquisition  or  devel¬ 
opment  of  systems,  the  management  and 
engineering  functions  needed  for  devel¬ 
oping  system  hardware,  software,  and 
procedures  that  will  satisfy  the  require¬ 
ments  for  physical  and  information  se¬ 
curity,  Operational  Security  (OPSEC), 
Communications  Security  (COMSEC), 
and  Electronic  Security  (ELSEC). 

t  Ensures  that  system  acquisition  or 
development  includes  steps  to  counteract 
postulated  or  known  system  vulnerabili¬ 
ties  and  to  firmly  establish  system  secu¬ 
rity  as  the  result  of  effectively  app.'ving 
those  steps. 

«  Eliminates  through  engineering  and 
design  any  characteristics  that  could  re- 
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suit  in  the  deployment  of  systems  with 
operational  security  deficiencies. 

•  Makes  sure  aerospace  weapon  and 
support  systems  meet  Department  of 
Defense  (DoD)-specified  security  re¬ 
quirements. 

•  Assists  industrial  and  DoD  capabili¬ 
ties  expand  in  technologies  that  identify, 
measure,  and  mitigate  security  vulnera¬ 
bilities  in  weapon  and  support  systems. 

•  Identifies  illicit  interference  against 
a  system  or  subsystem  that  could  suc¬ 
ceed  in: 

-  Preventing  the  system  from  com¬ 
pleting  its  mission. 

-  Allowing  the  system  to  be  used 
in  a  way  that  could  be  interpreted  as  the 
beginning  of  an  armed  attack  by  the 
United  States. 

-  Causing  an  incident,  such  as  an 
in-place  nuclear  explosion  or  loss  of 
custody,  to  occur  that  would  embarrass 
the  United  States. 

•  Specifies  ihe  detection,  alarm  dis¬ 
crimination,  and  response  functions  that 
are  required  to  compensate  for  residual 
vulnerabilities. 

•  Qualitatively  and  quantitatively  de¬ 
fines  operational  security  requirements. 

Relationships  to  Other  Programs. 
Sometimes  the  security  program  satisfies 
system  requirements  by  providing  a  se¬ 
curity  response  capability;  other  times,  it 
is  a  part  of  an  overall  analysis  and  pre¬ 
sents  alternatives  to  prevent  introducing 
a  security  vulnerability  into  the  system 
design: 

•  SYSTEM  ACQUISITION.  System 
security  is  an  element  of  systems  acqui¬ 
sition  and,  as  such,  must  be  compatible 


with  the  activities  and  goals  of  system 
acquisition  in  its  various  phases. 

•  SYSTEM  ENGINEERING.  Security 
requirements  are  distinct  design  criteria 
that  become  part  of  the  engineering  de¬ 
sign.  They  appear  in  functional  de¬ 
scriptions  and  trade-off  loops.  They  are 
defined  and  documented  through  func¬ 
tional  analyses  in  the  same  way  as  oper¬ 
ational  design  criteria  are.  Sometimes, 
security  criteiia  influence  the  design  of 
contract  items  that  are  not  part  of  the 
security  subsystem.  And  sometimes, 
they  affect  the  design  of  the  weapon 
system  and  eliminate  the  need  for  secu¬ 
rity  subsystem  hardware. 

•  THE  SURVIVABILITY  AND 
VULNERABILITY  PROGRAM.  Secu¬ 
rity  vulnerability  analyses  contribute  to 
and  become  part  of  the  overall  surviv¬ 
ability  and  vulnerability  analyses,  which 
determines  whether  or  not  a  weapons 
system  can  survive  an  abnormal  hostile 
environment.  Part  of  the  data  for  sur¬ 
vivability  and  vulnerability  analysis  is 
output  from  security  vulnerability  anal¬ 
yses  or  vice-versa.  The  survivability 
and  vulnerability  analyses  address  a 
wider  range  of  threats  and  environment 
(mission  profile),  than  do  the  security 
vulnerability  analyses.  The  latter  ex¬ 
amine  the  possibilities  of  exploiting  each 
vulnerability  of  the  system  to  ground 
launched  adversary  assaults  and  consider 
the  occurrence  of  a  single  malevolent  act 
that  exploits  a  security  vulnerability  as 
unacceptable. 

•  THE  SYSTEM  SAFETY  PRO¬ 
GRAM.  The  security  system  is  subject 
to  safety  analysis  because  it  uses  facili¬ 
ties,  hardware,  people,  and  equipment 
that  must  be  kept  safe.  Also  system  re¬ 
quirements  for  safety  are  often  implicit 
in  the  requirements  for  security.  For 
example,  the  procedures  used  for  safety 
and  for  security  of  nuclear  resources 
often  minimize  deliberate  and  accidental 
acts  against  those  resources.  Nuclear 
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safety  requires  the  imposition  of  the 
two-person  concept  and  nuclear  security 
specifies  entry  control,  response  proce¬ 
dures,  and  procedures  for  enforcing  the 
two-person  concept.  Nuclear  safety 
analyses  tell  system  security  engineers 
how  much  time  and  how  many  tools 
someone  would  need  to  access  the  sys¬ 
tem’s  critical  components.  Security  vul¬ 
nerability  analyses  tell  nuclear  safety 
engineers  how  many  people  will  use 
what  tools  to  attack  the  system  and 
when  those  people  will  attack  the  sys¬ 
tem. 

•  SITING  OF  REAL  PROPERTY 
FACILITIES.  Facilities  and  access-road 
siting  criteria  affect  the  design  of  the 
security  system  because  the  responsive¬ 
ness  of  security  forces  is  affected  by 
where  the  facility  is  located. 

«  CONTRACTOR  MANAGEMENT. 
The  relationships  contractors  have  with 
associate  and  integrating  contractors  and 
subcontractors  influence  the  effective¬ 
ness  of  system  security  during  system 
design. 

Relationship  to  Other  Security  Pro¬ 
grams.  There  are  a  number  of  rela¬ 
tionships  with  other  security  programs 
that  complement  or  interact  with  each 
other  as  discussed  below  and  illustrated 
in  Figure  11-1: 

•  THE  PHYSICAL  SECURITY  PRO¬ 
GRAM.  This  program  counters  physical 
security  vulnerabilities  not  correctible  by 
design.  SSE  integrates  the  physical 
security  requirements  of  COMSEC, 
nuclear  safety,  chemical  and  biological 
defense,  etc.,  into  total  system  security. 

•  THE  PERSONNEL  INVESTI¬ 
GATION,  SECURITY  CLEARANCE, 
AND  ACCESS  CONTROL  PROGRAM. 
This  program  sets  up  a  way  to  assign 
loyal,  trustworthy  individuals  to  sensi¬ 
tive  positions.  It  is  augmented  by  the 
personnel  reliability  program  (PRP)  of 


the  SSE  management  program,  which 
verifies  that  otherwise  loyal  3nd  trust¬ 
worthy  individuals  are  stable  enough  to 
have  access  to  nuclear  weapons. 

•  THE  INFORMATION  SECURITY 
PROGRAM.  This  program  sets  the  cri¬ 
teria  for  assigning  information  security 
classification  and  the  requirements  for 
handling  known  or  suspected  compro¬ 
mise.  Based  on  these  criteria  and  re¬ 
quirements  and  on  the  results  of  SSE 
analyses,  the  program  managers  and 
system  security  engineers  decide  how  to 
classify  system  security  information. 

•  THE  INDUSTRIAL  SECURITY 
PROGRAM.  This  program  and  the  SSE 
management  program  mesh  because  SSE 
defines  critical  security  problems  that 
need  to  be  resolved  within  the  frame¬ 
work  of  DoD  5220.22-M,  Industrial  Se¬ 
curity  Manual  (ISM)  for  Safeguarding 
Classified  Information.  SSE  also  identi¬ 
fies  and  supports  requirements  that  de¬ 
viate  from  normal  practice  as  set  up  in 
the  ISM. 

•  COMSEC.  COMSEC  analyses  con¬ 
tribute  to  security  vulnerability  analyses. 
They  describe  the  deterrent  value  of 
technical  barriers  and  identify  threats  to 
COMSEC  subsystems.  COMSEC  pro¬ 
tects  communications  essential  for  oper¬ 
ation  of  the  system,  including  the  secu¬ 
rity  system.  And  SSE  protects  and  con¬ 
trols  access  to  COMSEC  elements.  SSE 
coordinates  and  integrates  COMSEC  and 
other  USAF  security  program  elements 
when  functions,  facilities,  and  proce¬ 
dures  have  multiple  security  roles. 

•  OPSEC.  OPSEC  assesses  the  extent 
to  which  each  operational,  administra¬ 
tive,  and  logistical  activity  affects  sys¬ 
tem  security.  It  specifically  assesses  re¬ 
search  and  development  programs  and 
acquisition  of  weapon  and  command  and 
control  and  communications  systems 
(AFR  55-30). 
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•  ELSEC.  ELSEC  a.id  system  secu¬ 
rity  operate  together  to  prevent  hostile 
access  to,  or  understanding  of,  our  elec¬ 
tromagnetic  emissions. 

5.0  SUMMARY 

•  Security  covers  both  classified  and 
unclassified  facilities,  hardware  and 
software,  and  also  documentation  that 
require  protection  and  special  handling 
procedures. 

•  The  charter  of  a  joint  program 
should  include  a  discussion  of  the  secu¬ 
rity  program,  the  responsibility  for  is¬ 
suance  of  security  guidance,  and  the 
identification  of  the  command  or  office 
that  will  provide  security  assistance  to 
the  program  as  required. 

•  A  security  guide  should  be  devel¬ 
oped  early  in  the  program  and  should  be 
prepared  by  an  individual  in  the  pro¬ 
gram  office,  who  is  well  versed  with  the 
overall  acquisition. 

•  The  wording  of  the  guide  should  be 
as  clear  and  unambiguous  as  possible  to 
minimize  any  possible  misunderstanding 
which  could  lead  to  the  compromise  of 
classified  equipment,  technology,  soft¬ 
ware  or  information.  Program  peculiar 
phrases  and  acronyms  should  only  be 
used  when  absolutely  necessary. 

•  The  security  guide  should  be  devel¬ 
oped  following  the  step^  and  procedures 
prescribed  by  DoD  Handbook  5200. 1-H. 

•  The  joint  program  manager  and  the 
technical  and  administrative  staff  must 
be  aware  of  when  and  whv  to  restrict 
technical  information  and  to  take  such 
actions  that  will  support  the  policies 
promulgated  in  DoD  Directive  5230.24, 

•  A  System  Security  Engineering 
(SSE)  Management  Program  should  be 
considered  for  implementation  by  the 
joint  program  manager. 


•  The  procedures  of  the  SSE  Man¬ 
agement  Program  define  the  methods 
and  actions  needed  to  determine  system 
or  equipment  vulnerability  to  ground- 
initiated  overt  or  covert  attacks. 

•  The  SSE  Management  Program  es¬ 
tablishes  life  cycle  physical  security  for 
systems  as  a  condition  of  applying  engi¬ 
neering  and  design  principles  and  devel¬ 
oping  required  countermeasures  and 
procedures. 

•  In  certain  cases,  the  security  pro¬ 
gram  will  satisfy  system  requirements  by 
providing  a  security  response  capability; 
other  times,  the  security  program  will 
only  be  a  part  of  an  overall  analyses  and 
present  alternatives  to  prevent  intro¬ 
ducing  a  security  vulnerability  into  a 
system’s  design. 

•  There  are  a  number  of  relationships 
between  the  SSE  Management  Program 
and  other  security  programs  that  com¬ 
plement  or  interact  with  each  other  such 
as  the  Physical  Security  Program;  the 
Personnel  Investigation,  Security  Clear¬ 
ance,  and  Access  Control  Program;  the 
Information  Security  Program;  the  In¬ 
dustrial  Security  Program;  plus  COM- 
SEC,  OPSEC,  and  ELSEC. 
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CHAPTER  12 

RECENT  DoD  ACQUISITION  IMPROVEMENT  EFFORTS 


1.0  SYNOPSIS 

This  chapter  discusses  recent  efforts  to 
improve  the  field  of  acquisition  within 
the  Department  of  Defense  (DoD)  in¬ 
cluding  the  establishment  of  the  Office 
of  the  Under  Secretary  of  Defense 
(Acquisition)  (USD(A)),  the  President’s 
Blue  Ribbon  Commission  on  Defense 
Management,  and  various  other  endeav¬ 
ors.  The  establishment  of  the  new  of¬ 
fice  of  the  Under  Secretary  of  Defense 
for  Acquisition  (USD(A))  is  discussed  in 
section  2.0  including  the  responsibilities 
as  currently  defined  in  the  USD(A) 
charter.  Section  3.0  presents  the  rec¬ 
ommendations  of  the  President’s  Blue 
Ribbon  Commission.  The  status  of  the 
Defense  Acquisition  Improvement  Pro¬ 
gram  and  a  description  of  each  initiative 
is  provided  in  section  4.0,  and  other  re¬ 
lated  acquisition  improvement  efforts 
are  cited  in  section  5.0.  Finally,  a 
summary  of  the  chcoter  is  presented  in 
section  6.0. 

2.0  ESTABLISHMENT  OF  THE 
OFFICE  OF  UNDER  SECRETARY  OF 
DEFENSE  (ACQUISITION)  (USD(A)) 

The  post  of  Under  Secretary  of  Defense 
for  Acquisition  was  created  by  Congress 
under  the  1986  Military  Retirement 
Reform  Act  (Public  Law  99-348)  signed 
on  1  July  1986.  The  USD(A)  replaced 
the  Under  Secretary  of  Defense  for  Re¬ 
search  and  Engineering.  OSD  has  estab¬ 
lished  a  new  position  of  Director  of 
Defense  Research  and  Engineering.  In 
addition.  Congress  added  the  position  of 
Principal  (on  the  OSD  Organizaion 
Chart)  Deputy  Under  Secretary  of  De¬ 
fense  for  Acquisition,  in  the  Fiscal  1987 
Defense  Authorization.  In  September 
1986,  the  new  USD(A),  Richard  Godwin 
was  sworn  in.  On  10  February  1987, 
the  Deputy  Secretary  of  Defense  issued 
DoD  Directive  5 1 34 . 1  that  defined  the 


responsibilities,  functions,  relationships 
and  authorities  assigned  to  the  new 
USD(A).  The  directive  stated  that  the 
USD(A)  has  the  following  responsibili¬ 
ties  as  the  principal  staff  assistant  and 
advisor  to  the  Secretary  of  Defense  for 
all  matters  relating  to  the  acquisition 
processes,  as  well  as  research  and  devel¬ 
opment;  production;  logistics;  command, 
control,  communications,  and  intelli¬ 
gence  activities  related  to  acquisition; 
military  construction;  and  procurement. 
Accordingly,  the  USI)(A)  shall: 

•  Serve  as  the  Defense  Acquisition 
Executive  with  responsibility  for  super¬ 
vising  the  performance  of  the  entire 
DoD  acquisition  system  in  accordance 
with  the  policies,  provisions,  and  au¬ 
thorities  contained  in  DoD  Directive 
5000. 1^/  and  Office  of  Management  and 
Budget  (OMB)  Circular  No.  A- 1 09-^; 

•  Develop  policy  for  acquisition  plans 
and  strategies,  validate  program  acquisi¬ 
tion  requirements,  and  develop  acquisi¬ 
tion  program  guidance; 

•  Set  policy  for  acquisition  matters, 
including  contracting,  research  and  de¬ 
velopment,  production,  construction,  lo¬ 
gistics,  developmental  testing,  procure¬ 
ment,  and  training  and  career  develop¬ 
ment  of  acquisition  personnel; 

•  Set  policy  for  administrative  over¬ 
sight  of  defense  contractors; 

«  Serve  as  the  DoD  Procurement  Ex¬ 
ecutive,  with  responsibilities  as  pre¬ 
scribed  in  Executive  Order  12352-/  and 
41  U.S.C.  40 1-41 9— ;; 

•  The  Inspector  General,  DoD,  shall 
coordinate  audit  and  oversight  of 
contractor  activities  with  the  USD(A)  to 
prevent  duplication  of  effort  within  the 
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Department  and  unnecessary  duplicative  herence  to  approved  policies,  standards, 

oversight  of  contractors.  and  resource  planning  guidance; 


•  Serve  as  the  National  Armaments 
Director  and  Secretary  of  Defense  rep¬ 
resentative  to  the  Four  Power  Confer¬ 
ence.  Develop  memoranda  of  agree¬ 
ments  and  memoranda  of  understandings 
with  friendly  and  allied  nations  relating 
to  acquisition  matters;  and 

•  Chair  the  Defense  Acquisition 
Board  (DAB)  assisted  by  an  integrated 
structure  of  councils  and  committees 
that  relate  to  the  acquisition  process. 

For  each  assigned  area,  the  USD(A) 
shall: 

•  Direct  planning  and  special  studies 
to  analyze  and  evaluate  the  technical, 
economic,  and  military  worth  of  pro¬ 
grams  in  the  acquisition  system; 

•  Develop  policies,  conduct  analyses, 
provide  advice,  make  recommendations, 
and  issue  guidance  on  DoD  plans  and 
programs; 

•  Develop  systems  and  standards  for 
the  administration  and  management  of 
approved  DoD  acquisition  plans  and 
programs; 

0  Develop  plans,  programs,  actions, 
and  taskings  to  ensure  adherence  to  DoD 
policies  and  national  security  objectives, 
and  to  ensure  that  programs  and  systems 
are  designed  to  accommodate  cross-Ser- 
vice  operational  requirements  and  pro¬ 
mote  modernization,  consistent  with  the 
readiness,  sustainability,  and  efficiency 
of  the  Armed  Forces  of  the  United 
States  and  its  allies; 

•  Review  and  evaluate  recommenda¬ 
tions  on  requirements  and  priorities: 

•  Review  and  evaluate  DoD  Compo¬ 
nent  plans  and  programs  to  ensure  ad- 


9  In  conjunction  with  the  Assistant 
Secretary  of  Defense  (Comptroller) 
(ASD(C))  and  Director  of  Program 
Analysis  and  Evaluation,  review  pro¬ 
posed  resource  programs,  formulate 
budget  estimates,  recommend  resource 
allocations,  and  monitor  the  implemen¬ 
tation  of  approved  resource  programs; 

•  Fulfill  planning,  programming,  and 
budgeting  activities  relating  to  USD(A) 
responsibilities; 

•  Promote  coordination,  cooperation, 
and  mutual  understanding  of  all  matters 
related  to  assigned  activities,  both  inside 
and  outside  the  Department  of  Defense; 

•  Serve  as  primary  focal  point  and 
principal  spokesman  for  the  Department 
of  Defense  and  serve  on  boards,  com¬ 
mittees,  and  other  groups  pertaining  to 
assigned  functional  areas,  and  represent 
the  Secretary  of  Defense  on  USD(A) 
matters  outside  the  Department  of  De¬ 
fense; 

•  Develop  and  maintain  information 
management  and  reporting  systems;  and 

•  Perform  such  other  duties  as  the 
Secretary  of  Defense  may  prescribe. 

As  indicated  above,  the  USD(A)  has 
broad  authority  to  coordinate  and  super¬ 
vise  all  elements  of  acquisition  in  DoD, 
including  serving  as  the  Defense  Acqui¬ 
sition  Executive,  DoD  Procurement  Ex¬ 
ecutive  and  the  Chairman  of  the  De¬ 
fense  Acquisition  Board  (DAB).  The 
directive  further  specifies  that  the 
USD(A)  will  have  the  authority  to  direct 
the  Service  Secretaries  on  all  matters 
within  the  cognizance  of  the  USD(A), 
such  as  policy,  procedures  and  the  exe¬ 
cution  of  the  acquisition  system.  It 
should  be  noted,  however,  that  members 
of  Congress  and  the  USD(A)  have  ex- 
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pressed  their  concern  about  DoDD 
5134.1,  particularly  with  regard  to  the 
USD(A)  not  having  more  omnipotent 
authority  such  as  in  his  relationships 
with  the  Secretaries  of'  the  Services  and 
their  recourse  to  the  Secretary  of  De¬ 
fense  regarding  acquisition  matters.  The 
Secretary  of  Defense  has  advised  the 
directive  will  be  revised  to  have  Service 
Secretaries  recourse  to  USD(A).  If  the 
matter  cannot  be  resolved,  the  USD(A) 
would  refer  the  matter  to  the  Secretary 
of  Defense. 

In  addition,  the  structure  of  the 
USD(A)’s  office  is  currently  being  de¬ 
fined.  The  USD(A)  has  advised  that  his 
office  will  be  organized  around  four 
major  functional  areas:-/ 

«  System  Development.  Consisting  of 
two  offices  -  the  Director  of  Defense 
Research  and  Engineering  (DDR&E)  and 
the  Assistant  Secretary  of  Defense  for 
Command,  Control  Communications,  and 
Intelligence  ASD(CsI).  The  DDR&E 
will  be  in  -harge  of  basic  research  and 
will  serve  as  the  USD(A)’s  scientific  ad¬ 
viser  on  development  programs.  The 
DDR&E’s  duties  will  include  technol¬ 
ogy,  exploration/validation,  concept 
definition,  engineering  development, 
prototyping,  modifications  and  upgrades, 
and  foreign  technology  evaluation.-' 

•  Program  Operations.  Consisting  of 
a  new  office  to  develop  a  uniform  ac¬ 
quisition  information  system  for  the  en¬ 
tire  DoD  acquisition  process.  The  in¬ 
formation  system  is  envisioned  to  main¬ 
tain  track  of  program  status  within  a 
thirty  (30)  day  timeframe,  as  compared 
to  the  previous  tracking  system  that 
provided  information  that  was  ninety 
(90)  to  one  hundred  twenty  (120)  days 
old. 

In  addition,  the  program  operations  of¬ 
fice  will  be  responsible  for  long-range 
planning,  cost  and  program  analyses. 


service  acquisition  program  reviews,  and 
acquisition  personnel  training.-/ 

•  Material  Acquisition.  This  aiea  will 
be  managed  by  the  Assistant  Secretary 
of  Defense  for  Production  and  Logistics 
ASD(P&L),  who  will  advise  on  produc¬ 
tion  decisions.  The  ASD  will  be  in 
charge  of  procurement,  manufactur¬ 
ing/production,  contracting  policy,  in¬ 
dustrial  base,  productivity  and  quality 
assurance,  and  standardization  and  tech¬ 
nical  data  management.^ 

•  International.  All  international  ac¬ 
quisition  programs,  including  technology 
transfer  reviews,  are  being  consolidated 
into  a  single  office  as  a  unified  interface 
with  our  allies  and  friendly  nations  on 
acquisition  matters.^ 

Currently,  charters  delineating  the 
structure  and  responsibilities  of  the  De¬ 
fense  Acquisition  Board  (DAB)  and  its 
associated  committees,  are  in  formal  co¬ 
ordination.  This  is  a  significant  revision 
since  it  entailed  the  consolidation  of  one 
hundred  twenty  six  (126)  acquisition 
committees,  councils,  and  panels  that 
serve  the  DAB  into  ten  (10)  committees. 
The  committees  will  perforin  pre-re- 
views  for  the  DAB  and  coordinate  deci¬ 
sion  documents  among  the  Services  and 
offices  within  the  Office  of  the  Secre¬ 
tary  of  Defense  (OSD).^ 

As  one  of  the  USD(A)’s  first  efforts  to 
improve  the  acquisition  process,  USD(A) 
issued  a  Memorandum  for  the  Secre¬ 
taries  of  the  Military  Departments  and 
the  Director  of  Defense  Logistics 
Agency  on  11  March  1987  inst  estab¬ 
lished  a  procurement  regulatory  reform 
test  which  could  identify  ways  of  sim¬ 
plifying  and  accelerating  the  acquisition 
process.  With  the  memorandum,  the 
USD(A)  delegated  his  authority  to  issue 
class  deviations  to  the  Federal  Acquisi¬ 
tion  Regulation  (FAR)  and  DoD  FAR 
(DFAR),  and  waivers  of  any  DoD  pro¬ 
curement  regulations  not  required  by 
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statute  or  executive  order,  to  the  service 
acquisition  executives,  who  could  re- 
delegate  the  authority  to  the  assistant 
secretary  level.  The  goal  of  the  test  is 
to  make  it  easier  and  quicker  for  con¬ 
tracting  personnel  to  get  line  managers 
and  commanders  the  quality  products 
and  services  they  need,  when  they  need 
them,  The  test  effort  is  to  place  a 
strong  emphasis  on  quality  and  timeli¬ 
ness  as  well  as  price  to  get  the  best 
value  for  the  nation,  according  to  the 
memorandum.  In  addition,  the  memo¬ 
randum  stated  that  the  USD(A)  desired 
the  addressees  to  test  procurement  meth¬ 
ods  more  in  line  with  commercial  prac¬ 
tices  for  both  commercial  and  non¬ 
commercial  products  and  services.  The 
test  is  currently  underway  and  prelimi¬ 
nary  results  have  not  been  published. 

3.0  PRESIDENT’S  BLUE  RIBBON 
COMMISSION  ON  DEFENSE  MAN¬ 
AGEMENT 

In  July  1985,  President  Reagan  estab¬ 
lished  his  Blue  Ribbon  Commission  on 
Defense  Management  to  "study  the  issues 
surrounding  defense  management  and 
organization,  and  report  its  findings  and 
recommendations."  In  February  1986, 
the  Commission  delivered  an  Interim 
Report  to  the  President-7  that  provided 
initial  recommen  iations  regarding  key 
aspects  of  national  security  planning  and 
budgeting,  military  organization  and 
command,  acquisition  organization  and 
procedures,  and  Government-industry 
accountability.  The  Final  Report-'  pre¬ 
sented  the  Commission’s  complete  find¬ 
ings  and  recommendations  in  each  of  the 
areas  cited  above.  During  the  same  pe¬ 
riod  the  Commission  was  conducting 
their  study,  Congress  was  also  conduct¬ 
ing  hearings  regarding  the  DoD  man¬ 
agement  and  organization,  that  resulted 
in  the  enactment  of  the  Goldwater- 
Nichols  Department  of  Defense  Reorga¬ 
nization  Act  of  1986. The  Act  incor¬ 
porated  a  number  of  actions  recom¬ 
mended  by  the  Commission’s  study  and 


the  USD(A)  has  subsequently  pursued 
the  recommended  actions  since  being 
confirmed. 

In  the  area  of  acquisition  organization 
and  procedures,  the  Commission  made 
the  following  recommendations: 

•  The  creation  by  statute  of  a  new 
position  of  Under  Secretary  of  Defense 
(Acquisition)  and  authorization  of  an 
additional  Level  II  appointment  in  the 
Office  of  the  Secretary  of  Defense 
(OSD).  (That  is  -  the  USD(A)  should  be 
a  Level  II  Presidential  appointee  with  a 
solid  industrial  background  in  the  man¬ 
agement  of  complex  technical  programs.) 
In  addition,  the  USD(A)  should  set 
overall  policy  for  procurement  and  Re¬ 
search  and  Development  (R&D),  super¬ 
vise  the  performance  of  the  entire  DoD 
acquisition  system,  and  establish  policy 
for  the  administrative  oversight  and  au¬ 
diting  of  defense  contractors. 

e  The  Army,  Navy,  and  Air  Force 
should  each  establish  a  comparable  se¬ 
nior  position  filled  by  a  top-level  civil¬ 
ian  Presidential  appointee.  The  role  of 
the  Services’  Acquisition  Executives 
would  mirror  that  of  the  Defense  Ac¬ 
quisition  Executive.  They  would  ap¬ 
point  Program  Executive  Officers 
(PEO),  each  of  whom  would  be  respon¬ 
sible  for  a  reasonable  and  defined  num¬ 
ber  of  acquisition  programs.  Program 
Managers  for  these  programs  would  be 
responsible  directly  to  their  respective 
PEO  and  report  only  to  him  on  program 
matters.  Each  Service  should  retain 
flexibility  to  shorten  this  reporting  chain 
even  further,  as  it  sees  fit.  This  effort 
could  shorten  unambiguous  lines  of  au¬ 
thority  that  would  streamline  the  acqui¬ 
sition  process  and  cut  through  bureau¬ 
cratic  layering.  By  this  means,  the  DoD 
could  substantially  reduce  the  number  of 
acquisition  personnel. 

t  Congress  should  work  with  the  Ad¬ 
ministration  to  recodify  all  federal 
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statutes  governing  procurement  into  a 
single  government- wide  procurement 
statute.  This  recodification  should  aim 
not  only  at  consolidation,  but  more  im¬ 
portantly,  at  simplification  and  consis¬ 
tency. 

•  DoD  must  be  able  to  attract,  retain, 
and  motivate  well  qualified  acquisition 
personnel.  Significant  improvements, 
along  the  lines  of  those  recommended  in 
November  1985  by  the  National 
Academy  of  Public  Administration, 
should  be  made  in  the  senior-level  ap¬ 
pointment  system.  The  Secretary  of 
Defense  should  have  increased  authority 
to  establish  flexible  personnel  manage¬ 
ment  policies  necessary  to  improve  de¬ 
fense  acquisition.  An  alternate  person¬ 
nel  management  system,  modeled  on  the 
China  Lake  Laboratory  demonstration 
project,  should  be  established  to  include 
senior  acquisition  personnel  and  con¬ 
tracting  officers  as  well  as  scientists  and 
engineers.  Federal  regulations  should 
establish  business-related  education  and 
experience  criteria  for  civilian  contract¬ 
ing  personnel,  which  will  provide  a  basis 
for  the  professionalism  of  their  career 
paths.  Federal  law  should  permit  ex¬ 
panded  opportunities  for  the  education 
and  training  of  all  civilian  acquisition 
personnel.  This  is  necessary  if  DoD  is 
to  attract  and  retain  the  caliber  of  peo¬ 
ple  necessary  for  a  quality  acquisition 
program. 

•  The  Joint  Requirements  and  Man¬ 
agement  Board  (JRMB)  should  be  co¬ 
chaired  by  the  Under  Secretary  of  De¬ 
fense  (Acquisition)  and  the  Vice  Chair¬ 
man  of  the  Joint  Chiefs  of  Staff.  The 
JRMB  should  play  an  active  and  impor¬ 
tant  role  in  all  joint  programs  and  in 
appropriate  Service  programs  by  defin¬ 
ing  weapons  requirements,  selecting  pro¬ 
grams  for  development,  and  providing 
thereby  an  early  trade-off  between  cost 
and  performance. 


•  Rather  than  relying  on  excessively 
rigid  military  specifications,  DoD  should 
make  much  greater  use  of  components, 
systems,  and  services  available  "off  the 
shelf.-’  It  should  develop  new  or  cus¬ 
tom-made  items  only  when  it  has  been 
established  that  those  readily  available 
are  clearly  inadequate  to  meet  military 
requirements. 

•  A  high  priority  should  be  given  to 
building  and  testing  prototype  systems 
and  subsystems  before  proceeding  with 
full-scale  development.  This  early  phase 
of  R&D  should  employ  extensive  infor¬ 
mal  competition  and  use  streamlined 
procurement  processes.  It  should 
demonstrate  that  the  new  technology 
under  test  can  substantially  improve 
military  capability,  and  should  as  well 
provide  a  basis  for  making  realistic  cost 
estimates  prior  to  a  full-scale  develop¬ 
ment  decision.  This  increased  emphasis 
on  prototyping  should  allow  for  the 
concept  "fly  and  know  how  much  it  will 
cost  before  the  buy.” 

•  The  proper  use  of  operational  test¬ 
ing  is  critical  to  improving  the  opera¬ 
tions  performance  of  new  weapons. 
Accordingly,  operational  testing  should 
begin  early  in  advanced  development 
and  continue  through  full-scale  devel¬ 
opment,  using  prototype  hardware.  The 
first  units  that  come  off  the  limited-rate 
production  line  should  be  subjected  *o 
intensive  operational  testing  and  the 
systems  should  not  enter  high-rate  pro¬ 
duction  until  the  results  from  these  tests 
are  evaluated. 

0  To  promote  innovation,  the  role  of 
the  Defense  Advanced  Research  Projects 
Agency  should  be  expanded  to  include 
prototyping  and  other  advanced  devel¬ 
opment  work  on  joint  programs  and  in 
areas  not  adequately  emphasized  by  the 
Services. 

0  Federal  law  and  DoD  regulations 
should  provide  for  substantially  in- 
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creased  use  of  commercial-style  compe¬ 
tition,  relying  on  inherent  market  forces 
instead  of  governmental  intervention. 
To  be  truly  effective,  such  competition 
should  emphasize  quality  and  established 
performance  as  well  as  price,  particu¬ 
larly  for  R&D  and  for  professional  ser¬ 
vices. 

•  DoD  should  fully  institutionalize 
"baselinin  "  for  major  weapons  systems 
at  the  initiation  of  full-scale  engineering 
development.  Establishment  of  a  firm 
internal  agreement  or  baseline  on  the 
requirements,  design,  production,  and 
cost  of  weapons  systems  will  enhance 
program  stability. 

•  DoD  and  Congress  should  expand 
the  use  of  multiyear  procurement  for 
high-priority  systems.  This  would  lead 
to  greater  program  stability  and  lower 
unit  prices. 

•  DoD  must  recognize  the  delicate 
and  necessary  balance  between  the 
Government’s  requirement  for  data  and 
the  benefit  to  the  nation  that  comes 
from  protecting  the  private  sector’s  pro¬ 
prietary  rights.  That  balance  must  exist 
to  foster  technological  innovation  and 
private  investment  which  is  so  important 
in  developing  products  vital  to  our  de¬ 
fense.  DoD  should  adopt  a  data  rights 
policy  that  reflects  the  following  princi¬ 
ples: 

-  If  a  product  has  been  developed 
with  private  funds,  the  government 
should  not  demand,  as  a  precondition 
for  buying  that  product,  unlimited  data 
rights  even  if  the  government  provides 
the  only  market.  The  government 
should  acquire  only  the  data  necessary 
for  installation,  operation  and  mainte¬ 
nance. 

-  If  a  product  is  to  be  developed 
with  joint  private  and  government 
funding,  the  government’s  needs  for 
data  should  be  defined  during  contract 


negotiations.  Government  contribution 
to  development  funding  should  not  au¬ 
tomatically  guarantee  it  rights  to  all 
data. 

-  If  a  product  is  developed  entirely 
with  government  funds,  the  government 
owns  all  the  rights  to  it  but  may  under 
certain  circumstances  make  those  rights 
available  to  the  private  sector. 

Finally,  the  Commission  recommended 
that  the  President,  through  the  National 
Security  Council,  establish  a  compre¬ 
hensive  and  effective  national  industrial 
responsiveness  policy  to  support  the  full 
spectrum  of  potential  emergencies. 
Also,  that  the  Secretaiy  of  Defense,  with 
advice  from  the  Joint  Chiefs  of  Staff, 
respond  with  a  general  statement  of 
surge  and  mobilization  requirements  for 
basic  wartime  defense  industries,  and 
logistic  needs  to  support  those  industries 
and  the  essential  economy.  The  DoD 
and  Service  Acquisition  Executives 
should  consider  this  mobilization  guid¬ 
ance  in  formulating  their  acquisition 
policy,  and  program  managers  should 
incorporate  industrial  surge  and  mobi¬ 
lization  considerations  in  program  exe¬ 
cution. 

4.0  THE  DEFENSE  ACQUISITION 
IMPROVEMENT  PROGRAM 

The  Department  of  Defense  (DoD)  im¬ 
plemented  the  Defense  Acquisition  Im¬ 
provement  Program  (also  known  as  the 
Carlucci  Initiatives)  in  1981.  Originally, 
the  program  consisted  of  thirty-two  (32) 
management  initiatives  that  addressed 
long  standing  problems  with  major 
weapon  systems  acquisition,  including 
significant  cost  overruns  and  schedule 
slippages.  In  1983,  DoD  focused  high- 
level  management  attention  on  the  ini¬ 
tiatives  involving:—1 1 

•  program  stability, 

•  multiyear  procurement, 
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•  economic  production  rates, 

«  realistic  budgeting, 

•  readiness  and  support,  and 

•  competition. 

Subsequently,  in  1984,  the  DoD  added 
an  additional  initiative  involving  ways  to 
enhance  the  defense  industrial  base.^ 
The  initiatives  are  identified  in  Table 
12-1  along  with  the  status  of  imple¬ 
mentation.  The  purpose  of  each  initia¬ 
tive  is  presented  below,  except  for  ini¬ 
tiative  number  1,  Principles,  and  initia¬ 
tive  number  23,  Implementation,  that 
are  embodied  in  the  other  initiatives.  In 
addition,  several  others  are  consolidated 
under  general  headings  as  will  be 
noted.^' 

•  Preplanned  Product  Improvement  - 
to  ensure  a  lower  risk  approach  to 
weapon  system  design  to  reduce  unit 
costs  and  decrease  the  time  needed  to 
field  new  equipments. 

•  Multiyear  Procurement  -  to  reduce 
acquisition  costs  and  to  improve  product 
quality  by  stimulating  capital  equipment 
investments. 

•  Program  Stability  -  to  reduce  ac¬ 
quisition  costs  and  time, 

•  Capital  Investment  -  to  encourage 
capital  investment  by  DoD  contractors  to 
increase  their  productivity  and  lower 
weapon  systems  costs. 

•  Realistic  Budgeting  (including  bud¬ 
get  to  most  likely  cost,  budget  for  risk, 
and  budget  for  inflation)  -  to  reduce  the 
cost  growth  in  weapon  systems  resulting 
from  understated  and  overly  optimistic 
program  and  budget  estimates,  and  to 
enhance  program  stability. 


•  Economic  Production  Rates  -  to  re¬ 
duce  the  cost  and  time  needed  to  field  a 
weapon  system  by  producing  systems  at 
more  economic  rates. 

•  Contract  Type  -  to  balance  program 
needs  and  cost  savings  with  a  realistic 
assessment  of  contractor  and  Govern¬ 
ment  risk  by  ensuring  the  use  of  the  ap¬ 
propriate  contract  type. 

•  Weapon  System  Readings  and  Sup¬ 
port  (including  support  and  readiness, 
test  hardware,  contractor  incentives, 
visibility  of  logistics  and  support,  and 
"Fast  Track"  programs)  -  to  improve  the 
logistical  supportability  and  maintain¬ 
ability  of  weapon  systems  deployed  in 
the  field. 

•  Administrative  Costs/Time  -  to  re¬ 
duce  the  administrative  costs  and  time 
involved  in  procuring  items  by  raising 
the  threshold  authority  for  small  pur¬ 
chases  and  eliminating  unnecessary  pa¬ 
perwork. 

•  Government  Legislation  -  to  iden¬ 
tify  and  revise  as  necessary,  acquisition 
related  laws  and  regulations  that  are  an 
unnecessary  burden  on  the  acquisition 
process. 

•  DoD  Directives  -  to  reduce  the 
number  of  DoD  acquisition  directives, 
the  amount  of  contract  documentation, 
and  contract  requirements  which  are  not 
cost  effective,  thereby  reducing  program 
costs. 

•  Funding  Flexibility  -  to  provide 
DoD  more  funding  flexibility  by  ob¬ 
taining  statutory  authority  to  transfer 
funds  from  procurement  to  R&D  for  in¬ 
dividual  weapon  system  programs  with¬ 
out  prior  approval  of  Congress  or  OMB, 
and  increasing  reprogramming  thresholds 
for  both  procurement  and  R&D  pro¬ 
grams. 
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TABLE  12-1  DEFENSE  ACQUISITION  IMPROVEMENT 
PROGRAM  STATUS  ISf  U / 


INITIATIVES 

IMPLEMENTATION 

FULL 

PARTIAL 

1 .  Principlas 

0 

2.  Preplanned  improvements 

0 

3.  Multiyear  procurement 

• 

4.  Program  stability 

0 

5.  Capitel  investment 

0 

6.  Budget  to  most  likely  cost 

0 

7.  Economic  production  rates 

0 

8.  Contract  type 

• 

9.  Support  and  readiness 

0 

10.  Administrative  costs/time 

0 

11.  Budget  for  risk 

0 

12.  Test  hardware 

0 

13.  Government  legislation 

0 

14.  DOD  directives 

0 

15.  Funding  flexibility 

• 

16.  Contractor  incentives 

0 

17.  Briefing  and  data  requirements 

• 

18.  Budget  for  inflation 

0 

1 9 .  Forecast  business  base 

0 

20.  Source  selection 

0 

21 .  Standard  systems 

0 

22.  Design  to  cost 

0 

23.  Implementation 

0 

24.  Reduce  milestones 

0 

25.  Link  acquisition/budgeting 

0 

26.  Acquisition  council 

0 

27.  Defense  Acquisition  Executive 

0 

28.  Thresholds  for  milestone  reviews 

0 

29.  Integrate  acquisition/ budgeting 

0 

30.  Visibility  of  logistics/support 

0 

31 .  "Fast  Track"  programs 

0 

32.  Competition 

0 

33.  Defense  industrial  base 

0 
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•  Acquisition  Decisionmaking  Process 
(including  briefing  and  data  require¬ 
ments,  reducing  milestones,  and  thresh¬ 
olds  for  milestone  review)  -  to  decen¬ 
tralize  acquisition  decisionmaking,  and 
thereby  reduce  the  administrative  time 
and  costs  associated  with  major  decision 
points  in  the  acquisition  process  for 
major  weapon  systems. 

•  Forecast  Business  Base  ••  to  develop 
and  maintain  a  data  base  covering  busi¬ 
ness  base  conditions  at  major  defense 
plants  for  use  in  planning  acquisition 
strategy  and  developing  realistic  cost  es¬ 
timates. 

«  Source  Selection  -  to  improve  the 
source  selection  process  by  placing 
added  emphasis  on  the  contractor’s  past 
performance,  schedule  realism,  facilities 
planning,  and  cost  credibility. 

•  Standard  Systems  -  to  develop  and 
use  standard  operational  and  support 
systems  to  achieve  earlier  deployment 
and  better  support  of  weapon  systems. 

•  Design  to  Cost  -  to  better  control 
weapon  systems  costs  by  providing  con¬ 
tractual  incentives  to  industry  that  more 
closely  associate  Design  to  Cost  (DTC) 
goals  with  actual  costs. 

«  Linking  and  Integrating  Acquisition 
and  Budgeting  -  to  help  ensure  that 
proposed  new  program  starts  are  af¬ 
fordable  within  DoD’s  planning,  pro¬ 
gramming  and  budget  constraints;  and 
that  acquisition  decisionmaking  mile¬ 
stone  reviews  consider  whether  suffi¬ 
cient  resources  have  been  committed  to 
carry  out  the  program. 

•  Acquisition  Council  -  to  give  the 
Services  a  greater  and  more  active  role 
in  the  major  systems  acquisition  process. 

•  Defense  Acquisition  Executive  -  to 
clearly  designate  the  principal  advisor  to 


the  Secretary  of  Defense  for  defense  ac¬ 
quisitions,  now  the  USD(A). 

«  Competition  -  to  increase  the  use  of 
competition  in  the  acquisition  process  to 
reduce  costs,  improve  contractor  per¬ 
formance,  and  enhance  the  industrial 
base. 

•  Defense  Industrial  Base  -  to  en¬ 
hance  the  industrial  base  resonsiveness 
to  DoD’s  needs. 

Efforts  are  continuing  to  fully  imple¬ 
ment  all  of  initiatives  by  the  USD(A), 
the  Assistant  Secretary  of  Defense  for 
Acquisition  and  Logistics,  and  the  Ser¬ 
vice  Secretaries  and  their  acquisition 
executives. 

5.0  RELATED  ACQUISITION  IM¬ 
PROVEMENT  EFFORTS 

Additional  efforts  to  improve  the  acqui¬ 
sition  process  for  major  weapon  systems 
also  relate  to  the  recommendations  of 
the  President’s  Blue  Ribbon  Commission 
presented  in  section  3.0  and  the  Defense 
Acquisition  Improvement  Program  ini¬ 
tiatives  cited  in  section  4.0  and  are  pro¬ 
vided  below: 

•  The  ASD  (A&L)  is  working  on  a 
five  point  agenda  that  includes  all  three 
sectors  of  the  defense  acquisition  com¬ 
munity,  DoD  personnel,  Congress  and 
industry  according  to  the  following  pri¬ 
ority:^ 

1.  To  enhance  the  defense  indus¬ 
trial  base, 

2.  To  improve  the  quality  of  de¬ 
fense  systems, 

3.  To  improve  the  professionalism 
of  the  DoD  acquisition  workforce, 

4.  To  overcome  the  adversarial  re¬ 
lationship  with  industry,  and 
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5.  To  streamline  the  legislative  and 
regulatory  constraints  on  the  acquisition 
process. 

•  The  Deputy  Secretary  of  Defense 
issued  two  directives  designed  to  estab¬ 
lish  uniform  training,  education  and  ex¬ 
perience  requirements  for  both  military 
and  civilian  procurement  personnel, 
DoD  Directive  5000.48  and  DoD  Direc¬ 
tive  5000.23.i2/ii/ 

•  Section  1622  of  Title  10,  U.S.  Code 
states  that  before  being  assigned  to  duty 
as  a  Program  Manager,  a  person:  (1) 
must  have  attended  the  Program  Man¬ 
agement  Course  at  the  Defense  Systems 
Management  College  (DSMC)  or  a  com¬ 
parable  program  management  course  at 
another  institution;  and  (2)  must  have  at 
least  eight  years  experience  in  the  ac¬ 
quisition,  support,  and  maintenance  of 
weapon  systems,  at  least  two  of  which 
were  performed  while  assigned  to  a 
procurement  command. 

•  USD(A)  is  restructuring  the  acqui¬ 
sition  decisionmaking  milestones  to  in¬ 
clude  two  new  milestones,  and  is  also 
enhancing  milestone  0,  New  Start,  to 
improve  the  validation  of  the  mission 
need  and  associated  system  requirements 
and  the  establishment  of  a  baseline  plan, 
Milestones  I  through  III  will  remain  es¬ 
sentially  unchanged.  A  new  Milestone 
IV  regarding  the  readiness  and  support 
phase,  and  a  new  Milestone  V  concern¬ 
ing  the  operational  phase  will  be  added. 
Milestone  V  would  address  program 
modifications  and  provide  the  basis  for 
new  start  decisions.— ^ 

6.0  SUMMARY 

«  The  USD(A)  position  was  created 
by  Congress  in  1986  to  function  as  the 
principal  staff  assistant  and  advisor  to 
the  Secretary  of  Defense  for  all  matters 
relating  to  the  DoD  acquisition  system; 
R&D;  production,  logistics,  a  id  C3I  ac¬ 


tivities  related  to  acquisition;  military 
construction;  and  procurement. 

«  The  office  of  the  USD(A)  is  being 
organized  around  four  functional  areas: 
System  Development;  Program  Opera¬ 
tion;  Material  Acquisition;  and  Interna¬ 
tional  Acquisition  Programs. 

#  Charters  defining  the  structure  and 
responsibilities  of  the  DAB  and  its  ten 
(10)  associated  committees  are  currently 
in  formal  coordination.  The  committees 
will  perform  pre- reviews  for  the  DAB 
and  coordinate  decision  documents 
among  the  Services  and  offices  within 
the  Office  of  the  Secretary  of  Defense. 

e  The  USD(A)  has  established  a  pro¬ 
curement  regulatory  reform  test  to  iden¬ 
tify  ways  of  simplifying  and  accelerating 
the  acquisition  process. 

9  The  President’s  Blue  Ribbon  Com¬ 
mission  on  Defense  Management  com¬ 
pleted  their  year  long  study  and  sub¬ 
mitted  the  results  and  recommendations 
in  a  report  to  the  President  in  June 
1986.  The  report  included  recommen¬ 
dations  regarding  key  aspects  of  national 
security  planning  and  budgeting,  mili¬ 
tary  organization  and  command,  acqui¬ 
sition  organization  and  procedures,  and 
Government-industry  accountability. 
During  the  same  period,  Congress  was 
also  conducting  hearings  on  DoD  man¬ 
agement  and  organization  that  resulted 
in  the  Goldwater-Nichols  DoD  Reorga¬ 
nization  Act  of  1986. 

9  DoD  has  been  pursuing  the  Defense 
Acquisition  Improvement  Program  since 
1981  to  inprove  the  acquisition  process. 
Of  the  thirty-three  (33)  initiatives  iden¬ 
tified  in  the  program,  DoD  has  fully 
implemented  ten  (10)  and  is  in  various 
stages  of  implementation  in  the  other 
twenty-three  (23). 

9  The  ASD  (A&L)  is  working  on  a 
five  point  agenda  that  includes  all  three 
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sectors  of  the  defense  acquisition  com¬ 
munity,  DoD  personnel,  Congress,  and 
industry. 


2/  "Goldwater-Nichols  Department  of  Defense 
Reorganisation  Act  of  1986,"  Public  Law  99-433  of 
1  October  1986. 


•  The  Deputy  Secretary  of  Defense 
has  issued  two  directives  designed  to 
establish  uniform  training,  education, 
and  experience  requirements  for  both 
military  and  civilian  procurement  per¬ 
sonnel. 

•  The  USD(A)  is  restructuring  the  ac¬ 
quisition  decisionmaking  milestones  by 
enhancing  Milestone  0  and  adding  Mile¬ 
stones  IV  and  V  to  cover  readiness  and 
support,  and  operations  respectively. 


1 J  DoD  Directive  5134.1,  "Under  Secretary  of 

Defense  (Acquisition),"  10  February  1987. 

2/  DoD  Directive  5000.1,  "Major  System  Acqui¬ 
sitions,"  12  March  1986. 

2/  Office  of  Management  end  Budget  Circular 
No.  A- 109,  "Major  Syatem  Acquieitiona,"  5  April 
1976. 

4/  Executive  Order  12352,  "Federal  Procurement 
Reform*,"  17  March  1982. 

6/  Title  41,  United  Statee  Cods,  Section*  401- 
419,  "The  Office  of  Federal  Procurement  Policy 
Act,"  a*  amended. 

6/  "Defenie  Acqui»ition  Organisation,"  Federal 
Contracto  Report.  Vol.  47,  No.  10,  The  Bureau  of 
National  Affaire,  Inc.,  Washington,  D.C.,  9  March 
1987,  p.  378. 

7/  "A  Formula  for  Action  -  A  Report  to  the 
President  on  Defense  Acquisition,"  the  President's 
Blue  Ribbon  Commission  on  Defense  Management, 
April  1986. 

8/  "A  Quest  for  Excellence  -  Final  Report  to  the 
President,"  the  President's  Blue  Ribbon  Commission 
on  Defense  Management,  June  1986. 


10/  "DoD’s  Defense  Acquisition  Improvement  Pro¬ 
gram:  A  Status  Report,  GAO/NSIAD-86-148, 

General  Accounting  Office,  July  1986,  p.l. 

11/  "Status  of  the  Defense  Acquisition  Improve¬ 
ment  Program’s  S3  Initiatives,"  GAO/NSIAD-86- 
178BR,  General  Accounting  Office,  September  1986, 
pp.  2-3. 

12/  "DoD  Nominees'  Five-Point  Agenda  Includes 
Acquisition  Workforce,  Congress,  Industry,"  Federal 
Contracts  Report,  Vol.  46,  No.  23,  The  Bureau  of 
National  Affairs,  Inc.,  Washington,  D.C..  12  Decem- 
bsr  1986,  p.  1001. 

13/  DoD  Dirsctive  5000.48,  "Experience,  Educa¬ 
tion  and  Training  Requirements  for  Personnel  As¬ 
signed  to  Acquisition,"  9  December  1986. 

14/  DoD  Directive  5000.23,  "System  Acquisition 
Management  Careers,"  9  December  1986. 

15/  "Two  New  Milestones,"  Federal  Contracts  Re¬ 
port,  Vol.  47,  No.  10,  The  Bureau  of  National  Af¬ 
fairs,  Inc.,  Washington,  D.C.,  9  March  1987,  p.  378. 
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CHAPTER  13 

LESSONS  LEARNED  AND  SUCCESSFUL  PROGRAMS 


1.0  SYNOPSIS 

This  chapter  discusses  a  number  of 
lessons  learned  as  a  result  of  managing 
joint  programs,  some  successful  and 
others  not  so  successful.  By  reviewing 
lessons  learned,  Joint  Program  Office 
personnel  should  benefit  in  their  man¬ 
agement  by  applying  the  knowledge  of 
recommended  approaches  and  actions  to 
their  program.  Section  2.0  provides  a 
general  discussion  regarding  joint  pro¬ 
grams  and  lessons  learned.  Next,  section 
3.0  presents  general  considerations  based 
on  actual  joint  program  experience. 
Prime  examples  of  successful  programs 
are  identified  and  several  are  discussed 
regarding  the  reasons  they  were  suc¬ 
cessful  in  section  4.0.  A  summary  of 
the  chapter  is  provided  in  section  5.0. 

2.0  DISCUSSION 

Since  practically  every  joint  program 
will  have  certain  peculiarities,  not  every 
joint  program  will  encounter  or  experi¬ 
ence  the  same  problemmatic  situations. 
However,  similar  situations  may  occur 
which  if  recognized,  anticipated  or 
planned  for,  could  benefit  an  ongoing 
program. 

Joint  Programs  require  considerably 
more  planning,  coordinating  and  time 
consuming  effort  to  accomplish,  then  do 
single-service  programs.  As  Rear  Ad¬ 
miral  Freeman,  then  Commandant  of 
DSMC,  stated  in  1979,  and  which  is  still 
applicable  today:^ 

"...  the  word  joint  does  not  neconarily  nun  to- 
getherneio.  Moit  program!  are  the  reeuR  of  forced 
marriage*  .  .  .  Clearly  joint  program*  require  the 
very  fineil  in  management  ikille,  particularly  from 
the  Program  Manager  .  .  ." 

When  a  joint  acquisition  program  is  de¬ 
cided  on,  the  lead  service  usually  ap¬ 


points  the  Program  Manager  (PM)  and 
the  PM’s  organization  and  conduct  of 
the  acquisition  is  normally  governed  by 
a  charter  that  usually  emphasizes  the 
management  philosophy  of  the  lead  ser¬ 
vice.  The  charter  though  coordinated 
with  the  participating  services,  may 
subsequently  become  an  item  of  issue  as 
the  program  is  implemented.  Personnel 
participating  in  a  joint  program  have 
divided  loyalties,  to  the  joint  program 
and  their  service  affiliation.  The 
strengths  of  the  loyalties  can  depend  on 
numerous  factors,  from  their  sense  of 
responsibility  and  concern  to  protect 
their  service’s  interests,  to  consideration 
of  future  ramifications  on  promotions 
and  reassignments  that  may  result  from 
their  joint  program  tour  of  duty.^ 

Likewise,  numerous  other  interreactions 
between  the  joint  program  office  and 
the  involved  Services,  both  leading  and 
participating,  can  cause  impacts,  such  as 
priority  changes  of  service  programs  and 
related  funding,  program  emphasis  and 
interest  within  the  Service,  degree  of  in¬ 
volvement  in  the  joint  program,  or 
changes  in  performance  requirements  or 
threat.  Further,  in  many  instances, 
these  impacts  do  not  occur  at  appropri¬ 
ate  times  in  the  acquisition  process.**' 

As  stated  previously  in  this  guide,  as 
well  as  in  a  number  of  other  sources, 
including  the  Defense  Science  Board 
Study  of  1983,^  the  objective  of  a  Joint 
Program  is  to: 

o  Increase  military  effectiveness,  and 

•  Achieve  efficiencies  and  economies, 
if  possible. 

•  Plus,  exploit  technology  while 
considering  a  balance  between  tech¬ 
nology  and  requirements. 
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The  last  objective  is  especially  difficult, 
first  in  determining  the  extent  to  which 
the  technology  state-of-the-art  should 
be  projected  for  a  given  proposed  sys¬ 
tem  that  will  be  acceptable  to  all  Ser¬ 
vices  involved  in  the  joint  acquisition, 
and  second,  the  most  difficult,  the  joint 
agreement  of  the  involved  Services  on 
the  mission  need  and  doctrinal  require¬ 
ments.^ 

Service  positions  on  system  features  can 
become  critical  problem  areas  in  devel¬ 
oping  the  requirements  for  a  joint  sys¬ 
tem.  Negotiations  to  resolve  differences 
have  continued  from  several  months  up 
to  years  in  the  past.  In  certain  joint  ac¬ 
quisition  efforts,  involved  Services  have 
presented  long  lists  of  requirements, 
some  of  which  could  be  used  as 
"bargaining  chips"  rather  than  actual 
necessities.  Other  requirement  items 
were  essential  enviromcntal  factors  or 
critical  integration  considerations  with 
existing  systems.  In  addition,  agreement 
among  the  Services  on  the  priority  of 
their  listed  requirements  were  even  more 
difficult  to  achieve.-^ 

Sometimes  certain  requirments  may  in¬ 
advertently  be  omitted  at  the  start  or 
evolve  as  the  joint  development  of  re¬ 
quirements  progresses,  and  consequently 
impact  on  the  acquisition  plans,  sched¬ 
ules  and  cost.  Likewise,  when  require¬ 
ments  have  been  developed  through  ne¬ 
gotiation  and  compromise,  the  end 
product  may  not  achieve  the  perfor¬ 
mance  ojbectives  anticipated  by  some  of 
the  involved  Services.  In  some  in¬ 
stances,  this  has  resulted  in  the  devel¬ 
opment  of  variations  of  the  end  product 
or  the  withdrawal  of  a  Service  from  a 
joint  program. 

Joint  systems,  as  single-service  ones,  can 
take  eight  (8)  to  fifteen  (15)  years  to 
achieve  deployment.  During  the  1970s 
and  early  1980s,  many  joint  programs 
were  often  established  well  into  the  ac¬ 
quisition  process,  sometimes  beyond  en¬ 


gineering  development,  when  the  lead 
service  design  had  been  well  formulated. 
Accordingly,  there  was  considerable  re¬ 
luctance  to  modify  or  compromise  the 
design  to  satisfy  the  needs  identified  by 
the  participating  service  or  services.-/ 
Some  "out-of-step"  joint  programs  still 
exist,  however,  as  more  emphasis  is 
placed  on  the  jointness  of  system  acqui¬ 
sitions  before  the  Concept  Exploration 
Phase,  by  the  Joint  Chiefs  of  Staff  (JCS) 
and  the  Under  Secretary  of  Defense  for 
Acquisition  (USD(A)),  a  more  harmo¬ 
nious  .  environment  for  Joint  Program 
Managers  (PMs)  and  their  staffs,  and 
their  interfaces  with  both  lead  and  par¬ 
ticipating  services  should  occur. 

A  principal  lesson  learned  from  the 
"out-of-step"  joint  programs  is  that  the 
programs  have  a  great  propensity  for  re¬ 
verting  to  single-service  programs. 

3.0  LESSONS  LEARNED 

Lessons  learned  in  both  successful  and 
not  so  successful  joint  programs  can 
benefit  current  and  future  Program 
Managers  and  their  staffs.  As  men¬ 
tioned  in  section  2.0  above,  each  joint 
program  is  an  entity  unto  itself,  how¬ 
ever,  simlar  circumstances  and  actions 
necessitated  by  the  acquisition  process 
will  occur,  and  with  them  possible 
problemmatic  situations.  By  being 
alerted  to  such  situations  through  lessons 
learned,  pitfalls  may  be  eliminated  or  at 
least  the  severity  reduced. 

Lessons  learned  based  on  actual  joint 
program  experience  are  presented  be¬ 
low:^ 

•  The  earlier  in  concept  formulation/ 
development  that  a  joint  charter  can  be 
established,  the  greater  the  probability 
of  program  success  and  ultimate  com¬ 
monality. 

•  The  need  for  strong,  flexible  lead¬ 
ership  cannot  be  overemphasized, 
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•  The  establishment  of  equitable 
management  and  engineering  procedures 
is  critical  to  the  ultimate  success  of  any 
joint  program. 

•  Understand  that  allowances  must  be 
made  for  differences  in  procedures  and 
approaches  among  the  Services. 

•  Joint  programs  produce  additional 
and  continuing  interest  among  higher 
authorities  in  each  involved  Service  as 
well  as  DoD  and  Congress,  that  will 
necessitate  requirements  for  additional 
briefings  and  communications. 

•  The  structure  of  the  joint  program 
office  (see  Table  1-1  and  Figure  6-1)  as 
well  as  the  emphasis  placed  upon  the 
program  by  DoD,  the  Services  and 
Congress,  will  have  a  decided  effect  on 
the  management  and  success  of  the  pro¬ 
gram.  The  increased  interest  in  the  ac¬ 
quisition  field,  including  joint  programs, 
by  Congress  and  DoD  during  recent 
years  was  illustrated  by  General  Skantze 
in  his  remarks  at  the  DSMC  PMC  Class 
86-1  convocation:^ 

"On  Capital  Hill  10  ysars  ago,  (our  commit!,***  And 
SubcommitUe*  wroU  defense  legislation.  Last  year, 
by  one  count,  C4  had  at  it.  In  1983,  DoD  witneiaei 
gave  1,463  hours  of  testimony,  and  responded  to 
84,148  written  inquiries  and  692,150  telephone  re¬ 
quest*  Last  year  the  Congress  changed  1,800  sep¬ 
arate  programs.  There’s  been  an  explosion  of  man¬ 
dated  DoD  reports  and  studies;  from  30  in  1970  to 
458  in  1986.  That's  a  1,272  percent  increase.  How 
does  thul  affect  you?  Program  office  people  pro¬ 
vided  tlie  lion's  share  of  tire  data  for  those  reports 
and  testimonies." 


•  A  program’s  success  is  not  deter¬ 
mined  by  the  technological  state-of-the- 
art,  but  rather  by  the  associated  risks, 
and  these  risks  must  be  adequately 
funded  to  avoid  cost  overruns.^ 

•  Work  with  Services  to  baseline  all 
joint  programs  no  later  than  the  begin¬ 
ning  of  Full  Scale  Development 
Phase.^ 

•  To  the  maximum  extent  possible, 
ensure  the  accuracy  of  the  data  and  in¬ 
formation  used  in  the  program’s  man¬ 
agement,  and  also  ensure  that  the  same 
accurate  data  and  information  is  pro¬ 
vided  to  Congress,  DoD  and  the  Ser¬ 
vices.^ 

4.0  SUCCESSFUL  JOINT  PRO¬ 
GRAMS 

Of  all  the  joint  programs  in  recent  years 
including  those  cited  in  Appendix  F, 
certain  ones  have  been  recognized  by 
DoD  and  the  Services  as  prime  examples 
of  successful  major  programs: 

•  Advanced  Medium  Range  Air-to- 
Air  Missile  (AMRAAM), 

•  Defense  Satellite  Communications 
System  (DSCS), 

•  F-4  Aircraft, 

•  Hellfire  Missile, 

•  High  Speed  Antiradiation  Missile 
(HARM), 


«  Integrated  Electronic  Warfare  Sys- 
•  Logistics  is  one  of  the  most  diffi-  tem  (1NEWS), 

cult  areas  in  joint  program  efforts.  Un¬ 
like  many  other  interservice  issues  that  •  Joint  Cruise  Missile, 

can  be  resolved  by  escalation  to  higher 

decision  authority,  logistic  problems  a  NAVSTAR  GPS, 

must  be  settled  at  the  working  level  by 

specialists  through  an  effective  manager  •  Sidewinder  Missile, 

and  coordinator,—^ 
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•  V-22  (OSPREY)  Joint  Vertical  Lift 
Aircraft. 

The  prime  reasons  cited  for  the  success 
Ok  the  AMRAAM,  the  DSCS,  and  to  a 
degree,  the  F-4  Aircraft  programs  were 
the  resolution  of  requirement  issues  at 
the  onset  of  the  joint  programs,  and  the 
front-end  planning  and  settlement  of  as 
many  technical  and  management  issues 
as  possible.  Issues  to  be  resolved  should 
at  least  include  the  following:^ 

•  Operational  concepts, 

t  Performance  specifications  (in¬ 
cluding  operability  and  supportability), 

•  Technical  approaches  and  options, 

•  Configuration  constraints, 

•  Acquisition  strategy, 

•  Cost  and  schedule, 

•  Relative  worth  vis-a-vis  current 
and  alternative  systems, 

•  Management  structure. 

The  Hellfire  missile  was  designed  from 
the  onset  to  meet  common  performance 
requirements  of  the  Army,  Navy  and 
Marine  Corps.  There  was  one  differ¬ 
ence  between  the  AGM-114A  Hellfire 
(Army)  and  the  AGM-114B  Hellfire 
(Navy).  To  meet  Navy  shipboard  safety 
requirements,  the  AGM-114B  model  was 
designed  to  have  a  mechanical  Safety 
Arming  Device  (SAD)  to  prevent  acci¬ 
dental  firing  of  the  rocket  motor  by  the 
electromagnetic  fields  encountered  in 
shipboard  environments.  In  addition, 
the  Navy  Operational  Evaluation  (OP- 
EVAL)  testing  went  smoothly  subse¬ 
quent  to  the  Army  solving  inherent 
technical  and  performance  problems 
encountered  during  extensive  testing 
program  by  the  Army.  The  total  Navy 
test  program  was  completed  in  a  cost- 


effective  manner  using  Army  test  data, 
that  allowed  for  cost  savings  in  time  and 
money  compared  to  a  stand-alone  Navy 
program.  In  addition,  competition  in 
production  was  introduced  into  the  pro¬ 
gram  by  requiring  two  corporations, 
each  of  which  had  about  sixty-five  (65) 
percent  of  the  knowledge  required  to 
build  the  complete  missile,  to  share 
technical  data  packages  through  a  tech¬ 
nology  transfer  program  and  bid  to 
build  the  complete  missile.  Further,  the 
two  prime  contractors  compete  yearly  to 
determine  the  quantity  split.  This 
method  allows  the  low  bidder  to  receive 
up  to  seventy-five  (75)  percent  of  the 
total  contract  award.  This  combined 
effect  of  a  dual-source  procurement 
strategy  and  the  competitive  bidding 
process  has  significantly  reduced  the 
missile’s  flyaway  unit  cost  from  543,500 
per  unit  in  FY1984  to  $27,800  pe»  unit 
in  FY1986.  The  competition  benef'itted 
both  Services  and  the  Marine  Corps  by 
combining  requirements  and  procuring 
larger  quantities  that  resulted  in 
economies  of  scale  in  unit  costs.—1 1 

5.0  SUMMARY 

•  Program  Managers  and  their  staffs 
can  benefit  from  lessons  learned  in  sim¬ 
ilar  situations. 

•  Joint  programs  require  considerably 
more  planning,  coordinating  and  time 
consuming  effort  to  accomplish,  then  do 
single-service  programs. 

a  Personnel  participating  in  joint  pro¬ 
grams  have  divided  loyalties  -  to  the 
joint  program  and  to  their  service  affil¬ 
iations. 

•  Differences  in  which  the  Services 
view  the  joint  program,  such  as  in¬ 
volvement,  priority  or  funding,  can  in¬ 
pact  on  the  joint  program. 

•  Obtaining  a  joint  agreement  on  the 
mission  need  and  doctrinal  requirements 


13-4 


is  one  of  the  most  difficult  tasks  in  a 
joint  program  eifort. 

•  Agreement  by  the  Services  on  the 
priority  of  their  listed  requirements  is 
one  of  the  most  difficult  to  achieve. 

•  Staggered  entry  of  the  Services  into 
an  acquisition  program  can  impact 
severely  on  a  program  and  endanger  its 
probability  for  success. 

•  Regarding  lessons  learned,  the  fol¬ 
lowing  should  be  considered: 

-  Establish  a  joint  charter  as  soon 
as  possible. 

-  Provide  strong  and  flexible 
leadership. 

-  Establish  equitable  management 
and  engineering  procedures. 

-  Make  allowances  for  the  differ¬ 
ences  in  Services’  procedures  and  ap¬ 
proaches. 

-  Plan  for  additional  high  level 
briefings  and  communications. 

-  The  structure  of  the  joint  pro¬ 
gram  office  will  have  a  decided  effect 
on  the  management  and  success  of  the 
program. 

-  Special  attention  should  be  given 
to  logistics  as  it  is  one  of  the  most  dif¬ 
ficult  areas  in  joint  program  efforts. 

-  Consider  the  associated  risks  re¬ 
lated  to  the  planned  technological  state- 
of-the-art  of  the  system  being  acquired. 

-  Establish  a  system  baseline  be¬ 
fore  the  start  of  the  Full  Scale  Develop¬ 
ment  (FSD)  phase. 

-  Use  and  provide  the  same  accu¬ 
rate  data  and  information,  both  inter¬ 
nally  and  externally  to  the  program. 
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APPENDIX  A 

MEMORANDUM  OF  AGREEMENT  ON  THE  MANAGEMENT  OF 
MULTISERVICE  SYSTEMS/PROGRAMS/PROJECTS1 


1.  Purpose: 

This  Memorandum  establishes  policies 
for  implementing  multiservice  systems, 
program/project  management  in  ac¬ 
cordance  with  DoD  Directive  5000.1, 
"Acquisition  of  Major  Defense  Systems," 
13  July  1971.  It  is  the  basic  policy  doc¬ 
ument  for  management  of  multiservice 
systems,  programs  and  projects,  and  the 
framework  within  which,  like  DoD  Di¬ 
rective  5000.1,  acquisition  management 
procedures  must  operate. 

2.  Policy: 

The  Service  designated  as  the  Execu¬ 
tive  Agent  shall  have  the  authority  to 
manage  the  program/project  under  the 
policies  and  procedures  used  by  that 
Service.  The  Program/Project  Manager, 
the  Program/Project  Management  Of¬ 
fice,  and,  in  turn,  the  functional  ele¬ 
ments  of  each  Participating  Service  will 
operate  under  the  policies,  procedures, 
data,  standards,  specifications,  criteria 
and  financial  accounting  of  the  Execu¬ 
tive  Service.  Exceptions,  as  a  general 
rule,  will  be  limited  to  those  where  prior 
mutual  agreement  exists  or  those  essen¬ 
tial  to  satisfy  the  substantive  needs  of 
the  Participating  Services.  This  may  re¬ 
quire  the  Participating  Services  to  accept 
certain  deviations  from  their  policies 
and  procedures  so  as  to  accommodate 
the  assumption  of  full  program/project 
responsibility  by  the  Executive  Service. 
Demands  for  formal  reporting  as  well  as 
non-recurring  needs  for  information  wili 
be  kept  to  a  minimum. 

3.  Responsibilities: 

a.  The  Executive  Service  will: 

(1)  Assign  the  Program/Project 
Manager. 


(2)  Establish  an  official  manning 
document  for  the  Program/Project 
Management  Office  which  wiil  incor¬ 
porate  the  positions  to  be  occupied  by 
representatives  of  the  Participating  Ser¬ 
vices,  e.g.,  Department  of  the  Army 
Table  of  Distribution  and  Allowances 
(TDA)/Department  of  the  Navy  Man¬ 
power  Listing/Department  of  the  Air 
Force  Unit  Detail  Listing  (UDL).  The 
manning  document  developed  from  the 
Joint  Operating  Procedure  on  Staffing 
will  also  designate  a  key  position  for 
occupancy  by  the  Senior  Representative 
from  each  of  the  Participating  Services. 

(3)  Staff  the  Program/Project 

Management  Office  with  the  exception 
of  the  positions  identified  on  the  man¬ 
ning  document  for  occupancy  by  per¬ 
sonnel  to  be  provided  by  the  Participat¬ 
ing  Services.  Integrate  the  Participating 
Service  personnel  into  the  Pro¬ 

gram/Project  Management  Office. 

(4)  Be  responsible  for  the  admin¬ 
istrative  support  of  the  Program/Project 
Management  Office. 

(5)  Delineate  functional  tasks  to 
be  accomplished  by  all  participants. 

b.  The  Participating  Services  will: 

(1)  Assign  personnel  to  the  Pro¬ 
gram/Project  Management  Office  to  fill 
identified  positions  on  the  manning  doc¬ 
ument  and  to  assist  the  Program/Project 
Manager  in  satisfying  the  requirements 
of  ail  participants.  Numbers,  qualifica¬ 
tions  and  specific  duty  assignments  of 
personnel  to  be  initially  provided  by 
each  Participating  Service  will  be 
reflected  in  the  Joint  Operating 
Procedure. 

(2)  The  Senior  Representative 
from  each  Participating  Service  will  be 
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reflected  in  the  Joint  Operating  Pro¬ 
cedure. 

(2)  The  Senior  Representative 
from  each  Participating  Service  will  be 
assigned  to  a  key  position  in  the  Pro¬ 
gram/Project  Management  Office  and 
report  directly  to,  or  have  direct  access 
to,  the  Program/Project  Manager.  This 
key  position  could  include  assignment  as 
Deputy  to  Program/Project  Manager. 
He  will  function  as  his  Service’s  repre¬ 
sentative,  with  responsibilities  and  au¬ 
thorities  as  outlined  in  Paragraph  3.d  of 
this  Agreement. 

(3)  Provide  travel  funds  and  sup¬ 
port  necessary  for  the  accomplishment 
of  the  responsibilities  of  their  represen¬ 
tatives  in  the  management  of  the  Pro¬ 
gram/Project. 

(4)  Accomplish  Program/Project 
functional  tasks  as  specifically  assigned 
in  the  Charter,  in  the  Master  Plan  and 
Joint  Operating  Procedures  (JOPs),  or  as 
requested  and  accepted  during  the 
course  of  the  Program/Project. 

c.  The  Program/Project  Manager 
will: 

(1)  Satisfy  the  specific  opera¬ 
tional,  support  and  status  reporting  re¬ 
quirements  of  all  Participating  Services. 

(2)  Be  responsible  for  planning, 
controlling,  coordinating,  organizing  and 
directing  the  validation,  development, 
production,  procurement  and  financial 
management  of  the  Program/Project. 

(3)  Review,  on  a  continuing  ba¬ 
sis,  the  adequacy  of  resources  assigned. 

(4)  Assure  that  planning  is  ac¬ 

complished  by  the  organizations  respon¬ 
sible  for  the  complementary  functions  of 
logistics  support,  personnel  training, 

operational  testing,  military  construction 


and  other  facilities,  activation  or  de¬ 
ployment. 

(5)  Refer  to  the  appropriate  au¬ 
thority  those  matters  that  require  deci¬ 
sions  by  higher  echelons.  The  following 
items  will  be  referred  to  appropriate 
authority: 

(a)  Deviations  from  the  estab¬ 
lished  Executive  Service  policy  except  as 
specifically  authorized  by  the  Pro¬ 
gram/Project  documentation  (reference 
Paragraph  4  below). 

(b)  Increases  in  funding  of  the 
Program/Project. 

(c)  Changes  to  milestones  es¬ 
tablished  by  higher  authority. 

(d)  Program/Project  changes 
degrading  mission  performance  or  al 
tering  operational  characteristics. 

d.  Participating  Service  Senior 
Representative(s)  within  the  Pro¬ 
gram/Project  Management  Office  will: 

(1)  Speak  for  his  parent  Service 
in  all  matters  subject  to  the  limitations 
prescribed  by  his  Service.  Authority  of 
the  Service  Senior  Representative  is 
subject  to  the  same  limitations  listed 
above  for  the  Program/Project  Manager. 

(2)  Refer  to  his  parent  Service 
those  matters  which  require  decisions  by 
higher  echelons. 

4.  Documentation: 

Management  for  particular  Multiser¬ 
vice  Program/Projects  shall  be  docu¬ 
mented  by: 

(a)  A  Multiservice  Program/Project 
Manager  Charter.  The  responsible 
Commander  in  the  Service  having  prin¬ 
cipal  Program/Project  management  re¬ 
sponsibility  will  cause  the  preparation, 


negotiation  and  issuance  of  a  jointly  ap¬ 
proved  Charter  which  will  identify  the 
Program/Project  Manager  and  establish 
his  management  office.  The  Charter 
will  define  his  mission  responsiibility, 
authority  and  major  functions,  and  de¬ 
scribe  his  relationships  with  other  orga¬ 
nizations  which  will  use  and/or  support 
the  Program/Project.  The  Charter  will 
describe  and  assign  responsibility  for 
satisfying  peculiar  management  require¬ 
ments  of  Participating  Services  which 
are  to  be  met  in  the  Program/Project 
and  will  be  jointly  approved  for  the 
Headquarters  of  each  involved  Service 
by  persons  officially  appointed  to  ap¬ 
prove  such  Char  ters. 

(b)  A  Program/Pioject  Master  Plan. 
This  is  the  document  developed  and  is¬ 
sued  by  the  Program/Project  Manager 
which  shows  the  integrated  time-phased 
tasks  and  resources  required  to  accom¬ 
plish  the  tasks  specified  in  the  approved 
statement  of  need/performance  require¬ 
ments.  The  plan  will  be  jointly  ap¬ 
proved  for  each  involved  Service  by 
persons  officially  appointed  to  approve 
such  plans. 

(c)  Joint  Operating  Procedures 
(JOPs).  These  will  identify  and  describe 
detailed  procedures  and  interactions 
necessary  to  carry  out  significant  aspects 
of  the  Program/Project.  Subjects  for 
JOPs  may  include  Systems  Engineering, 
Personnel  Staffing,  Reliability,  Surviv¬ 
ability,  Vulnerability,  Maintainability, 
Production,  Management  Controls  and 
Reporting  (including  SAR),  Financial 
Control,  Test  and  Evaluation,  Training, 
Logistics  Support,  Procurement  and  De¬ 
ployment.  The  JOPs  will  be  developed 
and  negotiated  by  the  Program/Project 
Manager  and  the  Senior  Representatives 
from  the  Participating  Services.  An  op¬ 
tional  format  is  suggested  in  Attachment 
1  to  this  Agreement.  This  action  will  be 
initiated  as  soon  as  possible  and  accom¬ 
plished  not  later  than  180  days  after 
promulgation  of  the  Multiservice  P.  o- 


gram/Project  Manager  Charter.  Unre¬ 
solved  issues  will  be  reported  to  the 
Charter  approving  authorities  for  reso¬ 
lution. 

d.  Coordination/Communication. 
Where  Participating  .Services  are  af¬ 
fected,  significant  program  action,  con¬ 
tractual  or  otherwise,  will  not  be  taken 
by  the  Program/Project  Manager  with¬ 
out  full  consultation  and  coordination 
with  the  Participating  Services  while  the 
matter  is  still  in  the  planning 
stage.  All  formal  communications  from 
the  Program/Project  Management  Office 
to  higher  authority  in  the  Executive  or 
Participating  Services  v  ill  be  signed  by 
the  Program/Project  Manager  or  his 
designated  representative.  Substantive 
change  to  the  Charter,  Master  Plan,  or 
JOPs  will  be  negotiated  with  affected 
Participating  Services  prior  to  issuance 
as  an  approved  change.  No  restrictions 
will  be  placed  on  direct  two-way  com¬ 
munications  required  for  the  prosecution 
of  the  Program/Project  work  effort, 
other  than  that  required  for  security 
purposes. 

1  Atch 
JOP  Format 

We  approve  this  Memorandum  of 
Agreement  and  its  implementing  regula¬ 
tion. 

/s/HENRY  A.  MILEY,  JR. 

General,  USA 
Commanding  General 
US  Army  Materiel  Command 

/s/I.C.  KIDD,  JR. 

Admiral,  USN 

Chief  of  Naval  Material 

Naval  Material  Command 


/s/JACK  J.  CATTON 
General,  USAF 
Commander 
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Air  Force  Logistics  Command 

/s/GEORGE  S.  BROWN 
General,  USAF 
Commander 

Air  Force  Systems  Command 
20  July  1973 


Joint  AMC/NMC/AFLC/AFSC  Oper¬ 
ating  Procedure  format. 

I.  INTRODUCTION: 

This  paragraph  is  intended  to  give  a 
description  and  a  brief  review  of  the 
functional  area  of  interest  including  why 
the  JOP  is  necessary.  Outline  briefly 
the  overall  requirement  which  needs 
fulfillment. 

II.  SCOPE 

The  scope  will  outline  the  various  phases 
of  the  Program/Project  and  tie  down  the 
overall  limits  of  the  functional  area  of 
interest  in  terms  of  time  and  any  special 
provisions  or  limitations. 

III.  REFERENCES: 

Include  all  applicable  AMC/NMC/ 
AFLC/AFSC  regulations,  directives, 
etc.,  that  are  pertinent  to  the  functional 
area  of  interest. 

IV.  RESPONSIBILITIES: 

This  paragraph  is  intended  to  identify 
the  relationships  and  responsible  entities 
such  as  who  has  the  overall  management 
responsibility  and  who  has  the  support 
responsibility.  In  addition,  this  para¬ 
graph  should  describe  what  the  "product" 
or  the  effort  should  be. 

V.  PROCEDURES: 

This  paragraph  should  define  the  work 
to  be  accomplished  and  indicate  the 


main  steps  of  action,  including  coordi¬ 
nation,  which  are  required  to  conduct 
the  tasks  involved  properly  in  develop¬ 
ing  the  functional  area  of  interest. 

APPROVAL: 

Senior  Representative 
Participating  Service 

Program/Project  Manager 
Executive  Service 


Attachment  1 
FOOTNOTE: 

1.  This  memorandum  of  agreement  is  published 
as  a  joint  regulation,  AFLC/AFSC  K  80Q- 

2. AMCR  70-SQ/NAVMATINST  S000.10A. 
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APPENDIX  B 

CHARTER  FOR  THE  JOINT  SERVICES  ADVANCED  VERTICAL  LIFT 
AIRCRAFT  V- 22  OSPREY  PROGRAM  MANAGER  (PMA  275)1 


R  <■’/■'(  a) 

(b) 

(c) 

(d) 

(e) 

(f) 

(g) 

(h) 

(i) 

(j) 

(k) 

(D 

(m) 

(n) 


(o) 

(P) 

(q) 

(r) 


DEPSECDEF  memo  of  30  Dec  81.  Rotary  Wing  Aircraft  Development 
MOU  on  the  Joint  Services  Advanced  Vertical  Lift  Aircraft 
Development  Program  of  4  Jun  82 

DESPSECDEF  memo  of  8  Dec  82,  Joint  Services  Advanced  Vertical 
Lift  Aircraft 

USD  memo  of  27  Dec  82,  Joint  Services  Advanced  Vertical  Lift 
Aircraft 

Program  Budget  Decision  241 
DOD  Directive  5000.1  of  29  Mar  82 
DOD  Instruction  5000.2  of  8  Mar  83 

AFSCR/AFLCR  800-2/ AMUR  70-59/NAVMATINST  5000.10A,  Management 
of  Multiservice  Systems,  Programs,  and  Projects 
V-22  Osprey  Joint  Service  Operational  Requirement 
MO  A  for  V-22  Osprey  of  19  May  83 
Air  Force  Special  Order  0-41  of  26  May  83 

NAVAIRINST  5400. IB,  Naval  Air  Systems  Command  Headquarters 
Organizational  Manual 

NAVAIRINST  5000.8A,  Systems  Acquisition  Management  in  the 
Naval  Air  Systems  Command 

NAVAIRINST  5400.108,  Program/ Functional  Matrix  Management 
within  the  Naval  Air  Systems  Command 
NAVAIRINST  5451.87  w/CH-1 
SECNAVINST  5000.1  B,  System  Acquisition 
NAVAIRINST  1611.JG,  Submission  of  Fitness  Reports 

AR  700-129 /OPNAVINST  4105.2/ APR  800-43/MCO  11310.86,  Management  and 
Execution  of  Integrated  Logistic  Support  (JLS)  Programs  for  Multiservice  Acquisitions 


1.  Introduction. 

This  charter  provides  the  mission,  au¬ 
thority,  and  responsibility  of  the  Joint 
Services  Advanced  Vertical  Lift  Aircraft 
V-22  Osprey  Program  Manager  (PM) 
and  outlines  the  program’s  scope,  oper¬ 
ating  relationships,  organization,  and 
resources. 

a.  Joint  Service  Participation.  The 
Deputy  Secretary  of  Defense  recognized 
in  reference  (a)  the  need  for  joint  de¬ 
velopment  of  a  multimission  advanced 
vertical  lift  aircraft  for  the  1990’s.  The 
Army  was  designated  executive  service 
for  the  joint  development  effort  with 
the  Navy  and  Air  Force  as  participating 
services.  Initial  development  efforts 
were  outlined  in  references  (b)  and  (c) 


and  were  subsequently  modified  by 
reference  (d),  which  also  changed  desig¬ 
nation  of  the  executive  service  to  the 
Navy.  Reference  (e)  reflected  the 
Army’s  intention  only  to  procure  V-22 
aircraft  configured  to  meet  the  Marine 
Corps  mission.  Preparation,  develop¬ 
ment,  and  major  revisions  of  all  key 
program  documents  relating  to  sys¬ 
tem  specifications,  air-worthiness  quali¬ 
fication,  test  and  evaluation,  pro¬ 
gram/acquisition  plans  and  strategy,  and 
logistics  supportability  will  include  mul¬ 
tiservice  representation. 

b.  References.  This  program  will 
be  conducted  according  to  management 
principles  identified  in  references  (f), 
(g),  and  (h). 
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2.  System  Description. 

The  V-22  system  is  under  development 
as  a  vertical  lift  aircraft  using  advanced, 
but  mature,  technology  that  will  provide 
the  Navy,  Air  Force,  and  Marine  Corps 
with  a  self-deployable,  multimission 
vertical/short  take-off  and  landing 
capability  for  the  1990’s  and  beyond. 

3.  Mission. 

The  PM’s  primary  mission  is  to  pro¬ 
vide  the  Department  of  Defense  (DoD) 
operating  forces  with  a  fully  developed, 
supportable,  and  reliable  advancid  ver¬ 
tical  lift  aircraft  weapon  system  capable 
of  satisfying  operational  requirements, 
including,  but  not  limited  to,  the  fol¬ 
lowing:  Marine  Corps  assault  vertical 
lift;  Navy  combat  search  and  rescue;  and 
Air  Force  special  operations.  Specific 
mission  requirements  are  defined  in 
reference  (i).  In  addition,  the  PM  will 
manage  the  acquisition  and  support  of 
similar  systems  for  foreign  governments 
when  required  in  support  of  Defense 
Security  Assistance  Programs  (DSAPs). 

4.  Scope  of  the  Program. 

a.  The  scope  of  the  V-22  Program 
consists  of  the  definition,  development, 
test  and  evaluation,  acquisition,  initial 
support,  and  readiness  improvement  of 
the  weapon  system.  This  includes  sub¬ 
systems  and  components,  spares,  repair 
parts,  peculiar  and  common  support 
equipment,  weapon  system  train- 
e.  s/flight  simulators,  air  maintenance 
trainers,  and  all  supporting  technical 
documentation.  Initial  procurement  will 
be  for  DoD  components  with  potential 
procurement  for  foreign  governments. 

b.  Funds  listed  in  the  Five  Year 
Defense  Program  and  assigned  to  the 
PM  for  obligation  in  executing  program 
objectives  are  included  in  the  following 
research,  development,  test,  and  evalua¬ 
tion  program  elements:  Navy  63256/ 
64262N. 

(1)  When  required,  participating 
services’  funds  for  common  weapon 
system  development  will  be  identified 


on  military  interdepartmental  purchase 
rquests  prepared  by  the  cognizant  ser¬ 
vice. 

(2)  Additional  program  element 
funds  to  be  controlled  by  the  PM  may 
be  identified. 

5.  Program  Staffing  and  Organization. 

The  V-22  Program  will  be  planned, 
organized,  and  controlled  by  the  PM 
through  a  designated  joint  service  pro¬ 
gram  office.  Located  at  the  Naval  Air 
Systems  Command  Headquarters  (NAV- 
AIR),  this  program  office  will  respond 
to  the  requirements  of  the  executive  and 
participating  services  and  will  be  the 
single  point  of  contact  for  all  official 
actions  within  the  services  and  with 
industry  during  all  phases  of  the 
program. 

a.  In  keeping  with  the  requirements 
outlined  in  references  (h)  and  (j),  the 
PM  will  coordinate  with  the  Aeronauti¬ 
cal  Systems  Division  (ASD)  to  establish 
and  maintain  a  joint  staffing  document 
for  the  joint  program  office,  incorpo¬ 
rating  positions  to  be  occupied  by  rep¬ 
resentatives  from  each  service.  The  ini¬ 
tial  program  office  organization  and 
staffing  requirements  are  shown  in  ap¬ 
pendix  A.  The  individual  responsible 
foi  program  financial  matters  is: 

Financial  Execution  Officer: 

Michele  P.  Kenlon 

b.  The  program  office  will  be  ad¬ 
ministratively  supported  by  NAVAIR. 
This  support  will  include,  but  not  be 
limited  to,  military  personnel  services, 
space  allocations,  office  services, 
security,  graphic  arts,  and  com¬ 
munications.  Further,  this  support  will 
include  coordination  of  civilian  person¬ 
nel  services  administered  by  the  Con¬ 
solidated  Civilian  Personnel  Office, 
Crystal  City.  Travel  support  for  partici¬ 
pating  services  personnel  outside  the  V- 
22  Program  Office  will  be  provided 
following  respective  service  procedures. 


c.  In  keeping  with  reference  (k), 
whi'  h  authorized  establishment  of  an 
operating  location  at  the  V-22  Joint 
Program  Office  in  Crystal  City,  Vir¬ 
ginia,  effective  1  June  1983,  ASD  will 
establish  an  operating  location  at 
NAVAIRHQ  and  fili  the  civilian  and 
military  positions  a,  agreed  to  in  the 
joint  staffing  document.  The  Deputy 
for  Air  Force  Air  Vehicle,  as  senior  ser¬ 
vice  representative,  will  be  the  su¬ 
pervisor  of  all  Air  Force  military  and 
civilian  personnel,  as  well  as  chief  of 
the  operating  location,  reaurdless  of 
where  these  personnel  are  Physically 
located.  Specific  duties  and  responsibil¬ 
ities  of  these  personnel  will  be  assigned 
by  the  PM  in  consultation  with  the 
Deputy  for  Air  Force  Air  Vehicle. 

6.  Authorities  and  Responsibilities. 

Colonel  J.  A.  Creech,  USMC,  is  as¬ 
signed  as  the  PM  of  the  Joint  Services 
Advanced  Vertical  Lift  Aircraft  Pro¬ 
gram  (PMA275).  He  will  be  assisted  by 
the  Deputy  for  Marine  Air  Vehicle,  the 
Deputy  for  Navy  Air  Vehicle,  and  the 
Deputy  for  Air  Force  Air  Vehicle,  all  of 
whom  will  be  located  in  the  Program 
Office.  Further,  he  will  be  assisted  by 
the  Deputy  PM,  who  will  act  for  him  in 
his  absence. 

a.  General.  The  PM  is  the  Single 
central  executive  responsible  for  suc¬ 
cessfully  managing  the  program  and 
accomplishing  the  objectives  of  this 
charter.  He  has  broad  directive  author¬ 
ity  within  the  scope  of  the  program  over 
the  planning,  organization,  direction, 
control,  and  use  of  program  resources  to 
meet  DoD  requirements,  and  also  has 
authority  over  program  efforts  of  Navy 
in-house  and  contractor  organizations, 
including  assignment  of  responsibility  as 
appropriate  to  the  various  NAVAIRHQ 
functional  elements  following  the  overall 
framework  outlined  in  references  (1), 
(m),  (n),  and  (o).  As  the  responsible 
executive,  he  is  expected  to  act  on  his 
own  initiative  in  matters  affecting  the 
program.  In  those  cases  where  action  is 


required  beyond  the  authority  granted  in 
this  charter,  he  shall  refer  the  action  to 
higher  authority  in  the  Department  of 
the  Navy  with  his  recommendations,  in¬ 
cluding  alternatives  available. 

b.  Specific.  The  PM  is  delegated 
the  specific  authority  in  paragraph  1 1  of 
enclosure  (1)  to  reference  (p)  to  accom¬ 
plish  the  following  responsibilities. 

(1)  Manage  the  V-22  Program, 
including  establishing  a  baseline  and 
tracking  and  coordinating  changes  to 
that  baseline. 

(2)  Prepare  and  sign  fitness  re¬ 
ports  for  all  Navy  and  Marine  Corps 
military  personnel  (of  the  rank  of  com¬ 
mander  anti  below)  assigned  full  time  to 
the  Program  Office,  and  execute  per¬ 
formance  evaluations  for  applicable 
civilian  personnel  assigned  full  time  to 
that  office.  He  may  also  submit  con¬ 
current  fitness  reports  on  other  officers 
junior  to  him  and  concurrent  evaluations 
on  civilian  employees  from  other  com¬ 
mands  working  for  him  in  matrix  man¬ 
agement  under  the  authority  of  this 
charter.  In  keeping  with  reference  (q) 
guidance,  the  PM  will  prepare  a  letter 
of  evaluation  for  the  Deputy  for  Air 
Force  Air  Vehicle  and  submit  it  to 
his/her  rating  official. 

(3)  Respond  to  DSAP  require¬ 
ments.  When  required  by  the  recipient 
foreign  country,  the  PM  will  provide 
overall  initiation,  guidance,  coordina¬ 
tion,  and  review  of  DoD  efforts  in  lo- 
gistically  supporting  and  sustaining  in¬ 
country  inventory  of  weapon  systems 
under  his  cognizance,  The  PM  will  also 
maintain  close  liaison  with,  and  maxi¬ 
mum  responsiveness  to.  the  NAVAIRHQ 
Defense  Security  Assistance  Division 
(AIR- 103),  the  Naval  Supply  Systems 
Command  (SUP-07),  and  the  Office  of 
the  Chief  of  Naval  Operations  (OPNAV 
(OP-63))  on  DSAP  matters. 

c.  Conflict  Resolution.  When  con¬ 
flicts  between  program  and  functional 
policies  develop,  actions  directed  by  the 
PM  will  be  carried  out  pending  final 
resolution  of  such  matters.  Procedures 


for  resolving  conflict  are  addressed  by 
reference  (j). 

d.  Deputies  for  Service  Vehicles, 
The  executive  service  and  each  partici¬ 
pating  service  will  assign  a  deputy  for 
service  vehicle.  These  deputies  will  as¬ 
sist  the  PM  in  planning,  organizing,  co¬ 
ordinating,  controlling,  and  directing  the 
definition,  development,  production, 
procurement,  and  financial  management 
of  the  joint  program,  and  also  serve  in  a 
staff  position  in  all  joint  program  office 
matters.  As  such,  each  deputy  is  the 
primary  point  of  contact  between 
his/her  service  and  the  PM,  and  is  di¬ 
rectly  responsible  to  the  PM  for  program 
functions.  He/she  will  ensure  that  spe¬ 
cific  service  operational  and  logistics  re¬ 
quirements  and  service  positions  on  pro¬ 
gram  objectives  are  considered  and  met 
in  all  appropriate  elements  and  functions 
of  the  approved  joint  program.  He/she 
will  represent  his/her  service  in  matters 
related  to  the  management  and  coordi¬ 
nation  of  the  day-to-day  execution  of 
the  approved  joint  program  and  in  such 
other  matters  as  may  be  requested  by 
the  PM.  He/she  will  comply  with  es¬ 
tablished  executive  service  policies,  im¬ 
plementing  directives,  this  charter,  and 
joint  operating  procedures  (JOP’s); 
he/she  also  will  provide  input  to  and  re¬ 
view  program  issues  and  policies  as  they 
impact  service  interests. 

7.  Limitation  of  Authority. 

Limitation  of  the  PM’s  delegated  au¬ 
thority  are  as  follows: 

a.  He  does  not  have  the  authority 
to  deviate  from  established  policy. 

b.  Communication,  action,  or  inac¬ 
tion,  in  any  form,  which  contractors 
may  interpret  as  direction  will  be  con¬ 
ducted  through  the  appropriately  as¬ 
signed  contracting  officer. 

8.  Specific  Interface  and  Operating 
Relationships. 

(1)  Relationship  to  Chartering 
Authority.  The  P!vJ  receives  his  au¬ 


thority  from  and  is  ultimately  responsi¬ 
ble  and  accountable  to  the  Commander, 
Naval  Air  Systems  Command 
(COMNAVAIR)  for  the  discharge  of  the 
latter’s  responsibility  for  management  of 
the  V-22  Program.  The  PM  reports  di¬ 
rectly  to  the  Deputy  Commander  for 
Programs  (AIR-01),  who,  with  the  Di¬ 
rector  for  Anti-Submarine  Warfare  and 
Assault  Programs  (PDA -13),  provides 
policy  determination  and  requirements 
definition,  as  well  as  organizational  and 
administrative  support,  programming, 
and  life  cycle  coordination  among  all 
assigned  programs.  Matters  requiring 
COMNAVAIR's  attention  will  first  be 
coordinated  with  AIR-01  or  PDA- 13 
who  will,  if  possible,  accompany  the  PM 
to  see  COMNAVAIR.  When  neither 
AIR-01  nor  PDA- 13  is  available  and 
urgency  dictates  immediate  communica¬ 
tion  with  COMNAVAIR,  the  PM  will 
brief  AIR-01  or  PDA- 13  as  soon  as  they 
are  available. 

(2!>  Tasks.  The  PM  will  accom¬ 
plish  tne  following: 

(a)  Coordinate  appropriate  in¬ 
terface  segments  of  the  program  with 
other  program  managers,  systems  com¬ 
mands,  and  the  Chief  of  Naval  Opera¬ 
tions  (CNO)  staff  to  ensure  a  coordi¬ 
nated  OPNAV  effort,  and  establish  and 
promulgate  design  interface  specifica¬ 
tions  to  ensure  weapon  systems  integra¬ 
tion.  Unresolved  interface  problems 
will  be  referred  directly  to  the  appro¬ 
priate  senior  management  official  within 
OPNAV. 

(b)  Maintain  active  liaison 
with  cognizant  members  of  the  OPNAV 
staff  and  with  cognizant  program  coor¬ 
dinators  following  the  Navy  Program¬ 
ming  Manual.  The  PM  will  keep  them 
fully  informed  of  the  status  and  progress 
of  the  program  through  formal  and  in¬ 
formal  communication. 

(c)  Keep  the  Commander, 
Naval  Military  Personnel  Command 
(COMNA  VM1LPERSCOM)  fully  in¬ 
formed  of  military  personnel  re¬ 
quirements  of  the  weapon  system,  This 
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information  normally  will  be  transmitted 
to  COMNAVMILPERSCOM  through  the 
cognizant  program  coordinators  in  OP- 
NAV. 


(d)  Review  operational  re¬ 
quirements,  including  inventory  objec¬ 
tives  established  by  higher  authorities 
for  the  program,  to  ensure  timeliness, 
accuracy,  consistency,  and  compatibility 
with  program  plans  and  funding  avail¬ 
ability.  When  the  PM  cannot  resolve 
inconsistent  or  incompatible  require¬ 
ments  and  objectives,  he  will  submit  the 
problems  and  recommendations  in  writ¬ 
ing  to  COMNAVAIR  and  other  appro¬ 
priate  higher  authorities  for  resolution. 

(e)  Establish  appropriate  re¬ 
quirements  for,  and  monitor  the  acqui¬ 
sition  of,  special  or  additional  facilities 
necessary  to  support  test,  evaluation,  in¬ 
stallation,  operation,  and  maintenance  of 
V-22  systems  and  supporting  devices. 
He  will  ensure  that  facilities  planning 
factor  criteria  are  developed  with  Naval 
Facilities  Engineering  Command  Head¬ 
quarters  (Code  2013)  representatives  and 
published  in  NAVFAC  P-80;  and  he 
will  further  ensure  that  requirements  for 
new  facilities,  and  modifications  to  ex¬ 
isting  facilities,  are  made  known  to  par¬ 
ticipating  organizations  so  that  planning, 
programming,  and  construction  sched¬ 
ules  will  be  responsive  to  support  V-22 
systems. 


(f)  Maintain  liaison  with  cog¬ 
nizant  personnel  at  NAVAIR  test  and 
evaluation  activities  during  the  devel¬ 
opmental  test  and  evaluation,  and  jointly 
assure  COMNAVAIR  concerning  the 
readiness  of  the  systems  for  operational 
evaluation  and  fleet  use.  Further,  he 
will  maintain  active  liaison  with  cog¬ 
nizant  personnel  in  OPNAV,  the  Opera¬ 
tional  Test  and  .Evaluation  Force,  and 
the  Office  of  the  Secretary  of  Defense 
on  the  operational  test  and  evaluation  of 
the  weapon  system. 

b.  Air  Force  Unicue.  The  Head¬ 
quarters,  U.S.  Air  Force  (HQ  USAF)  has 
directed  Headquarters,  Air  Force  Sys¬ 
tems  Command  (HQ  AFSC')  participation 


via  Program  Management  Directive 
number  R-Q  3108  (2)/63256F;  and  HQ 
AFSC  has  outlined  ASD  participation  by 
AFSC  Form  56,  number  63256-84-21. 

(1)  Within  ASD,  the  Commander, 
ASD  has  tasked  the  Deputy  for  Airlift 
and  Trainer  Systems  (ASD/AF)  to  be  the 
single  focal  point  for  Air  Force  opera¬ 
tional,  technical,  business  management, 
financial,  configuration/data  manage¬ 
ment,  logistics  support  (with  Acquisition 
Logistics  Division  resources),  and 
test/evaluation  matters  unique  to  Air 
Force  equipment.  The  Deputy  for  Air 
Force  Air  Vehicle  will  ensure  proper 
coordination  with  ASD/AF. 

(2)  ASD/AF  has  the  responsibility 
and  authority  for  all  Air  Force  unique 
developments  as  agreed  to  in  a  JOP. 
ASD/AF  wiil  be  responsible  for  carrying 
out  service  program  direction  and  pro¬ 
viding  policy  and  decision  instructions, 
The  Deputy  tor  Air  Force  Air  Vehicle 
will  coordinate  these  activities  with  the 
Joint  Progiam  Office  and  ASD/AF. 

c.  JOP’s. 

(1)  JOP’s  may  be  negotiated  and 
executed  between  the  executive  and 
participating  services,  as  required,  to 
clearly  define  the  procedures  to  be  fol¬ 
lowed  by  each  service  in  meeting  total 
V-22  system  requirements.  Reference 
(j)  requires  that  JOP’s  for  integrated  lo¬ 
gistic  support  and  for  test  and  evalua¬ 
tion  be  developed.  The  following  areas 
are  candidate  subjects  for  additional 
JOP’s:  Engineering  cognizance,  configu¬ 
ration  management,  procurement  and 
production,  operational  flight  trainers, 
financial  management  and  status  re¬ 
porting  (program  control),  personnel 
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safety,  and  data  management.  Addi¬ 
tional  JOP’s  among  the  services  or  with 
other  agencies  may  be  authorized  as  ap¬ 
propriate  to  program  needs. 

(2)  The  joint  operating  agree¬ 
ments  appearing  in  reference(s)  will  be 
used  as  the  baseline,  where  appropriate, 
for  developing  the  JOP’s. 


(3)  The  PM  and  the  deputies  for 
service  vehicles  are  authorized  to  nego¬ 
tiate  JOP’s  for  their  respective  services, 
subject  to  their  parent  services’  unique 
requirements,  procedures,  and  approval. 
Cognizant  commands  will  assist  in  the 
negotiation  and  execution  of  these  pro¬ 
cedures  and  agreements. 

9.  Participating  Organizations,  Com¬ 
munication,  action,  or  inaction,  in  any 
form,  which  prime  contractors  may  in¬ 
terpret  as  direction  will  be  conducted 
through  the  appropriately  assigned 
NAVAIRHQ  contracting  officer. 

a.  NAVAIRHQ.  In  keeping 
with  the  NAVAIRHQ  concept  of  matrix 
management,  all  NAVAIRHQ  elements 
will  support  the  PM  and  his  staff  ac¬ 
cording  to  those  responsibilities  assigned 
in  references  (m),  (n),  (o),  and  (t).  The 
PM  is  authorized  direct  liaison  with  all 
NAVAIRHQ  divisions  and  directorates 
in  exercising  his  responsibilities.  When 
disagreement  occurs,  actions  directed  by 
the  PM  will  be  continued  or  instituted 
until  resolution. 

b.  Naval - Sislums _ Command. 

Naval  systems  commands  will  support 
the  PM  according  to  those  material  sup¬ 
port  responsibilities  assigned  by  CNM  in 
systems  command  charters,  reference 
(u). 

c.  Air  force.  HQ  USAF, 

HQ  AFSC,  and  Air  Force  Logistics 
Command  elements  will  support  the  PM 
as  required. 

d.  Marine  Corps.  Headquarters, 

U.S.  Marine  Corps  and  Marine  Corps 
Development  and  Education  Command 
elements  will  support  the  PM  as  re¬ 

quired. 

e.  Field  Activities.  Activities 

participating  in  the  execution  of  the 
program  are  listed  in  appendix  B,  and 
others  will  be  added  as  required.  These 
assignments  reflect  the  guidance  of  ref¬ 
erence  (p).  Direct  liaison  with  all  activ¬ 
ities  concerned  with  the  program  is  au¬ 
thorized.  Under  the  PM’s  guidance, 
formal  work  assignments  to  NAVAIR 
field  activities  will  be  coordinated  by 


the  appropriate  functional  organization 
in  NAVAIRHQ.  Deputies  for  service 
vehicles  will  coordinate  work  assign¬ 
ments  to  their  respective  services’  activ¬ 
ities,  initially  clearing  them  with  appro¬ 
priate  headquarters  organizations  fol¬ 
lowing  established  procedures. 

10.  Congressional  and  Public  Infor¬ 
mation. 

COMNAVA1R  is  responsible  for  coor¬ 
dinating  and/or  disseminating  public 
information  relative  to  the  program 
within  the  DoD,  to  legislative  bodies,  to 
industry,  and  to  the  general  public. 
This  responsibility  has  been  delegated  to 
the  NAVAIRHQ  Legislative  and  Public 
Affairs  Office  (AIR-07D). 

11.  Resources  Assessment. 

a.  The  PM  will  evaluate  and  docu¬ 
ment  the  effect  of  proposals  to  increase 
or  decrease  the  resources  authorized  for 
the  execution  of  the  program,  and  will 
determine  the  effect  of  proposed 
changes  on  approved  cost,  schedules, 
procurement  plans,  supportability,  and 
performance  objectives.  Officials  hav¬ 
ing  final  decision  authority  during  pro¬ 
gramming,  reprogramming,  and  budget¬ 
ing  deliberations  will  consider  the  PM’s 
evaluation. 

b.  The  PM  will  inform  the  Chief  of 
Naval  Operations  (and  others  as  directed 
by  COMNAVAIR)  via  the  chain  of 
command  of  any  instances  where  the  re¬ 
quirements  of  the  program  cannot  be 
met  within  the  resources  and  time 
available. 

12.  Program  Transition  or  Dises¬ 
tablishment. 

This  program  wiil  be  reviewed  period¬ 
ically  to  determine  if  it  has  accom¬ 
plished  its  objectives.  If  the  review  in¬ 
dicates  the  objectives  have  been  or  are 
about  to  be  accomplished,  the  PM  will 
develop  a  transition  plan  per  reference 
(m)  and  with  the  participating  services 
to  ensure  a  smooth  disposition  of 
remaining  resources,  responsibilities,  and 
functi  is. 


/%/  thomas  h.  mcmullen 

Lieutenant  General,  USAF 
Commander,  Aeronautical 
Systems  Division 


/s/  J.  B.  BUSEY 

Vice  Admiral,  USN 
Commander,  Naval  Air 
Systems  Command 


1/  The  charter  t>  baaed  on  Encloeure  1  to 
NAVAIUINST  5400. 1U4A,  and  revited  to  more  ac¬ 
curately  reflect  the  current  environment  of  the  V-22 
program. 
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ACTIVITY 

1.  Navv 

LOCATION 

TYPE  OF  WORK 
PERFORMED 

Naval  Air  Test  Center 

Patuxent  River,  MD 

Development 
test  and 
evaluation 

Naval  Air  Development 

Center 

Warminster,  PA 

Air  system 
and  aircraft 
system  deve¬ 
lopment 

Naval  Avionics  Center 

Indianapolis,  IN 

Avionics 
system  sup¬ 
port 

Operational  Test  and 

Evaluation  Force 

Norfolk,  VA 

Operational 

test 

Naval  Training  Equipment 
Center 

Orlando,  FL 

Training 

systems 

Naval  Air  Technical 

Training  Center 

Memphis,  TN 

Maintenance 

trainers 

Navy  Aviation  Supply 

Office 

Philadelphia,  PA 

Spares,spare 
parts,  and 
support 
equipment 
support 

Naval  Air  Technical 

Services  Facility 

Philadelphia,  PA 

Publications 
and  techni¬ 
cal  data 

Naval  Air  Engineering 

Center 

Lakehurst,  NJ 

Aircraft/ 

shipboard 

compati¬ 

bility 

Naval  Weapons  Center 

China  Lake,  CA 

Weapons 
test  support 

Naval  Weapons 

Engineering  Support 

Activity 

Washington,  DC 

Production 

support 
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Naval  Aviation  Logistics 
Center 


Naval  Air  Rework 
Facility 


Naval  Air  Rework 
Facility 


Naval  Air  Rework 
Facility 


Naval  Surface  Weapons 
Center 


David  W.  Taylor  Naval 
Ship  Research  and 
Development  Center 

Naval  Air  Propulsion 
Center 


Naval  Ordnance  Station 


Aeronautical  Systems 
Division 


Air  Force  Acquisition 
Logistics  Division 

Air  Force  Operational  Test  and 
Evaluation  Center 


Patuxent  River,  MD 


Cherry  Point,  NC 


Pensacola,  FL 


North  Island,  CA 


Dahlgren,  VA 


3ethesda,  MD 


Trenton,  NJ 


Indian  Head,  MD 


Wright-Palterson 
AFB,  OH 


Wright-Patterson 
AFB,  OH 

Kirtland  AFB,  NM 


TYPE  OF  WORK 


Logistics 

management 

assistance 

Maintenance 

engineering 

support 

Maintenance 

engineering 

support 

Maintenance 

engineering 

support 

Systems 
safety  assis¬ 
tance 

Wind  tunnel/ 

engineering 

support 

Propulsion 
and  power 
systems 

Cartridge 
activated  de- 


Aircraft  in¬ 
tegration 
support 

Logistics 

support 

Developmen¬ 
tal  oper¬ 
ational 
evaluation 
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TYPE  OF  WORK 


Air  Force  Systems 

Command 

Andrews  AFB,  DC 

Staff  sup- 
port/USAF 

Air  Force  Logistics 

Wright- Patterson 

Logistics 

Command 

AFB,  OH 

support 

Air  Force  Flight  Test 

Center 

Edwards  AFB,  CA 

Testing 

Electronic  Systems 

Division 

Hanscom  AFB,  MA 

Systems  inte¬ 
gration 

Armament  Development  and 

Test  Center 

3.  Matin?-  Coras 

Marine  Corps  Development 
and  Education  Command 

Egiin  AFB,  FL 

Systems  inte¬ 
gration 

Quantico,  VA 

Operational 
test  and 
evaluation 

4.  Other 

National  Aeronautics  and 

Space  Administration, 

Ames  Research  Lab 

San  Jose,  CA 

Technical 
services  and 
support 

National  Security  Agency 

Washington,  DC 

DSAP 

Defense  Intelligence 

Agency 

Washington,  DC 

Intelligence 

support 

Defense  Logistics 

Agency 

Alexandria,  VA 

Logistics 

support 

Defense  Contract  Audit 

Agency 

Alexandria,  VA 

Accounting 
services  and 
financial  ad¬ 
visory  sup¬ 
port 
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APPENDIX  C 

MEMORANDUM  OF  AGREEMENT  ON  MULTISERVICE 
OPERATIONAL  TEST  AND  EVALUATION  (MOT&E) 
AND  JOINT  TEST  AND  EVALUATION  (JT&E) 

15  MAY  1986 


1.  INTRODUCTION. 

a.  Purpose.  This  Memorandum  of 
Agreement  (MOA)  provides  a  basic 
framework  for  T&E  conducted  by  two 
or  more  OT&E  agencies  in  accordance 
with  DoD  Directive  (DoDD)  5000.3, 
Test  and  Evaluation.  12  March  1986. 

b.  Policy.  This  memorandum  pro¬ 
vides  guidelines  for  planning,  conduct¬ 
ing,  evaluating,  and  reporting  T&E  in¬ 
volving  two  or  more  OT&E  agencies. 
The  agreements  contained  herein  apply 
to  both  JT&E  and  MOT&E  (as  defined 
in  paragraph  c  below).  They  are  the 
standard  for  these  programs;  this  MOA 
may  be  supplemented  for  program- 
unique  considerations. 

c.  Definition  itf  Terms-  For  the 
purpose  of  this  memorandum,  the  fol¬ 
lowing  terms  are  defined: 

(1)  Deficiency  Report.  A  report 
of  any  condition  which  reflects  ad¬ 
versely  on  the  item  being  tested  and 
which  must  be  reported  outside  the  tost 
team  for  corrective  action. 

(2)  Executive  Agent/  Service.  See 
Lead  Service. 

(3)  Joint  T&E.  An  Office  of 
the  Secretary  of  Defense  (OSD)-directed 
T&E  program  structured  to  evaluate 
concepts  or  system  operational  or  tech¬ 
nical  performance  under  realistic  condi¬ 
tions  with  two  or  more  Services  partici¬ 
pating. 


(4)  Lead  Service.  The  Service 
designated  by  the  Secretary  of  Defense, 
or  as  a  result  of  Service  initiatives,  to  be 
responsible  for  management  of  a 
MOT&E  or  JT&E  program.  The  terms 
executive  agent  and  lead  Service  are 
considered  synonymous.  Lead  Service  is 
the  preferred  term. 

(5)  Multiservice  OT&E.  OT&E 
conducted  by  two  or  more  Services  for 
systems  to  be  acquired  by  more  than  one 
Service,  or  for  a  Service’s  systems  which 
have  interfaces  with  equipment  of  an¬ 
other  Service. 

(6)  Operational  Test  and  Evalua¬ 
tion.  Field  testing,  under  realistic  con¬ 
ditions,  of  any  item  of  (or  key  compo¬ 
nent  of)  weapons,  equipment,  or  muni¬ 
tions  for  the  purpose  of  determining  the 
effectiveness  and  suitability  of  the 
weapons,  equipment,  or  munitions  for 
use  in  combat  by  typical  military  users; 
and  the  evaluation  of  the  results  of  such 
tests. 

(7)  Support  Agent.  An  organiza¬ 
tion  that  provides  technical,  analytical 
assistance  to  the  Joint  Test  Director 
(JTD),  particularly  in  the  development 
of  the  feasibility  study,  test  design,  and 
in  preparation  of  the  test  report.  The 
agency  is  normally  a  federally  funded 
contract  research  center,  but  may  be  any 
DoD  organization  or  qualified  contrac¬ 
tor, 

(8)  Supporting  Service.  A  Service 
designated  by  the  Secretary  of  Defense, 
or  as  the  result  of  Service  initiatives,  to 
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assist  the  designated  lead  Service  in  the 
management  of  a  MOT&E  or  JT&E 
program. 

2.  COMMON  ELEMENTS  OF 
MULTISERVICE  OT&E  AND  JOINT 
T&E. 


(1)  The  designated  lead  Service 
will  have  the  overall  responsibility  for 
management  of  the  MOT&E  or  JT&E 
program  and  will  ensure  that  supporting 
Service  requirements  are  included  in 
formulation  of  the  basic  resource  and 
planning  documents.  The  supporting 
Service  will  ensure  that  all  of  their  re¬ 
quirements  are  made  known,  and  will 
assist  the  lead  Service  in  prosecution  of 
the  T&E  program.  Enclosures  (1)  and 

(2)  contain  guidelines  with  regard  to 
duties  and  responsibilities  of  participants 
which  will  be  considered  in  the  estab¬ 
lishment  and  conduct  of  all  MOT&E  and 
JT&E  test  programs. 


event  that  agreement  cannot  be  reached 
by  the  agency  commanders,  they  will 
refer  the  disagreement  to  their  respec¬ 
tive  Service  chiefs. 

b.  Resources.  The  lead  Service,  or 
before  the  designation  of  the  lead  Ser¬ 
vice  for  JT&E,  the  projected  lead  Ser¬ 
vice,  in  coordination  with  the  supporting 
Services  will  include  all  resource  re¬ 
quirements  in  a  JT&E  Consolidated  Re¬ 
source  Estimate  (CRE).  The  CRE  will 
contain,  as  a  minimum,  all  of  the  infor¬ 
mation  described  in  the  checklist  con¬ 
tained  at  enclosure  (7).  The  Test  and 
Evaluation  Master  Plans  (TEMPs)  can 
serve  this  purpose  for  MOT&E.  The 
supporting  Services  will  prepare  their 
portions  of  the  JT&E  CRE  in  their  for¬ 
mat  and  staff  them  through  their  normal 
Service  channels. 


c.  Funding.  Funding  for  JT&E 
and  MOT&E  will  be  in  accordance  with 
Chapter  251  of  DOD  71 10.1  -M,  the 

Service  directives. 


(2)  Provisions  will  be  made  on 
every  MOT&E  program  for  a  test  man¬ 
agement  council  (TMC)  which  will  ar¬ 
bitrate  all  disagreements  that  cannot  be 
resolved  at  the  working  level.  The  TMC 
will  be  composed  of  one  senior  repre¬ 
sentative  from  each  participating  agency 
headquarters  and  will  be  chaired  by  the 
lead  Service  representative. 

(3)  Issues  between  participants 
will  be  resolved  at  the  lowest  level  pos¬ 
sible.  It  is  anticipated  that  most  will  be 
resolved  either  internally  or  by  the 
TMC.  In  the  rare  event  that  agreement 
cannot  be  reached  at  or  below  tiie  TMC 
level,  each  party  to  the  disagreement 
will  prepare  position  papers  outlining 
the  problem,  the  position  taken  and  the 
supporting  rationale,  for  their  respective 
OT&E  agency  commander.  The  agency 
commanders  involved  will  confer  to  re¬ 
solve  the  disagreement.  In  the  unlikely 


(1)  The  individual  Services  will 
budget  for  funds  required  to  support 
their  individual  participation  in  MOT&E 
and  JT&E,  except  for  items  funded  by 
CSD. 

(2)  In  MOT&E,  each  Service  will 
budget  for  the  testing  necessary  to  ac¬ 
complish  their  assigned  test  objectives 
and  for  participation  of  their  personnel 
and  equipment  in  the  entire  test  pro¬ 
gram. 

(3)  In  OSD-directed  JT&E,  OSD 
disperses  PE  65804D  funds  to  the  test 
force  to  pay  for  ccsts  unique  to  the 
needs  of  a  joint  test.  On  rare  occasion, 
a  Service  may  fund  an  item  which  OSD 
should  fund;  in  these  instances,  negotia¬ 
tions  result  in  the  test  force  reimbursing 
the  Service.  Examples  of  these  costs  are: 
feasibility  studies  of  proposed  joint 
tests;  provisions  for  test  design  and 


C-2 


planning  support  for  selected  joint  tests; 
development,  procurement,  installation, 
and  operation  of  special  instrumentation; 
transportation,  travel,  and  per  diem  costs 
for  assigned  members  of  the  Joint  Test 
Director’s  staff;  modification  of  test  ar¬ 
ticles  to  permit  obtaining  test  data;  pro¬ 
visions  for  data  collection,  reduction 
analysis,  and  test  reporting  Services;  and 
reimbursable  costs  identified  in  DODD 
3200.11,  Use.  Management  and  Opera¬ 
tion  of  Department  of  Defense  Ranges 
and  Test  Facilities- 

3.  MULTISERVICE  OT&E, 

a.  QSD-Plrccted  MOT&E. 

MOT&E  planning,  conduct,  reporting, 
and  evaluation  shall  include  the  partici¬ 
pation  and  support  of  all  affected  DOD 
components,  including  the  Services’  op¬ 
erational  test  agencies. 

b.  Test  Team  Structure.  MOT&E 
may  be  conducted  by  a  multiservice  test 
team  or  concurrently  with  separate  test 
teams,  as  the  participating  agencies 
deem  necessary  for  a  given  program. 
The  basic  test  team  structure  is  shown  in 
enclosure  (3).  Service  test  teams  work 
through  a  Service  Deputy  Test  Director, 
or  a  senior  Service  representative.  The 
multiservice  Test  Director  will  exercise 
test  management  authority  over  re- 
qui/ements  and  efficient  scheduling  of 
test  events,  but  not  operational  control 
of  .he  test  teams.  The  Deputy  Test  Di¬ 
rectors  will  exercise  operational  control 
or  test  management  authority  over  their 
Service  test  teams  in  accordance  with 
their  Service  directives.  Additionally, 
they  will  act  as  advisors  to  the  multiser- 
vicc  Test  Director;  represent  their  Ser¬ 
vice’s  interests;  and  be  responsible,  at 
least  in  an  administrative  sense,  for  re¬ 
sources  and  personnel  provided  by  their 
Services.  Test  team  structure  below  the 
level  of  the  Deputy  Test  Director  will  be 
determined  on  a  program-by-program 
basis  by  the  individual  Services. 


c.  Test  Planning.  Test  planning 
for  MOT&E  will  generally  be  accom¬ 
plished  in  the  manner  prescribed  by  lead 
Service  directives.  The  below  listed 
general  procedures,  however,  will  be 
followed: 

(1)  The  lead  Service  OT&E 
agency  will  begin  the  planning  process 
by  issuing  a  call  to  the  supporting  Ser¬ 
vice  OT&E  agencies  for  critical  opera¬ 
tional  issues  (COIs)  and  test  objectives. 

(2)  The  lead  Service  OT&E 

agency  will  consolidate  these  COIs  and 
test  objectives  which  will  then  be  ap¬ 
proved  by  all  Services  OT&E  agencies 
involved  in  the  test.  Service-unique  is¬ 
sues  will  be  included  as  COIs  and/or 
objectives. 

(3)  The  lead  Service  OT&E 

agency  will  accommodate  supporting 
Service  OT&E  requirements  and  inputs 
in  the  forma!  coordination  action  of  the 
TEMP. 

(4)  Participating  OT&E  agency 

project  officers  will  meet  for  the  pur¬ 
pose  of  assigning  responsibility  for  ac¬ 
complishment  of  test  objectives  to  each 
OT&E  agency.  These  assignments  will 
be  made  in  a  mutually  agreeable  man¬ 
ner.  Each  agency  will  then  be  responsi¬ 
ble  for  resource  identification  and  ac¬ 
complishment  of  its  assigned  test  objec¬ 
tives  under  the  direction  of  the  lead 
Service  OT&E  agency. 

(5)  Each  participating  agency  will 
then  prepare  the  portion  of  the  overall 
test  plan(s)  for  its  assigned  objectives,  in 
the  lead  Service’s  test  plan(s)  format, 
and  will  identify  its  data  needs. 

(6)  The  lead  Service’s  OT&E 
agency  will  prepare  the  MOT&E  plan(s). 
consolidating  the  inputs  from  all  sup¬ 
porting  agencies.  After  consolidation, 
the  OT&E  plan(s)  will  be  coordinated 


with  the  supporting  Services’  OT&E 
agency, 

d.  Deficiency  Reporting  in  MOT&E. 

(1)  The  deficiency  reporting  sys¬ 
tem  of  the  lead  Service  will  normally  be 
used.  All  members  of  the  multiservice 
test  team  will  report  deficiencies  in  that 
system.  All  information  needed  by  the 
participants  will  be  collected.  Enclosure 
(5)  is  an  example  of  a  possible  form  to 
be  used  for  deficiency  reporting.  Each 
deficiency  report  will  be  coordinated 
with  all  Deputy  Test  Directors  prior  to 
release.  If  the  Test  Director  or  any 
Deputy  Test  Director  disagrees  with  the 
report,  he  may  attach  an  explanation  of 
his  disagreement  to  the  deficiency  re¬ 
port.  The  deficiency  report  will  then  be 
submitted  to  the  appropriate  developing 
agency  with  that  explanation  attached. 
The  underlying  philosophy  is  that  each 
participating  agency  will  be  allowed  to 
report  all  deficiencies  that  it  identifies; 
the  lead  Service  will  not  suppress  those 
reports.  Each  Deputy  Test  Director  will 
be  responsible  for  submitting  deficiency 
reports  into  his  own  Service’s  deficiency 
reporting  system  if  his  OT&E  agency  so 
requires. 

(2)  The  lead  OT&E  agency  will 
ensure  a  system  is  set  up  to  track  re¬ 
ported  deficiencies  and  to  provide  peri¬ 
odic  (monthly  is  preferred)  status  reports 
of  those  deficiencies  to  the  participating 
OT&E  agencies  and  to  the  test  team. 
Enclosure  (6)  identifies  the  minimum 
information  which  must  be  maintained 
in  the  tracking  system. 

(3)  Items  undergoing  test  will  not 
necessarily  be  used  by  each  of  the  Ser¬ 
vices  for  identical  purposes.  As  a  result, 
a  deficiency  considered  disqualifying  (a 
deficiency  deemed  to  be  of  such  mag¬ 
nitude  that  the  system  will  not  meet  a 
COI)  by  one  Service  is  not  necessarily 
disqualifying  for  all  of  the  Services. 
Deficiency  reports  of  a  disqualifying 


nature  must  include  a  statement  by  the 
concerned  Service  of  why  the  deficiency 
has  been  so  classified.  It  should  also 
include  statements  by  the  other  Services 
as  to  whether  or  not  the  deficiency  sig¬ 
nificantly  affects  them. 

(4)  In  the  event  that  one  of  the 
participating  Services  identifies  a  defi¬ 
ciency  that  it  considers  warrants  termi¬ 
nation  of  the  test,  the  circumstances 
should  be  reported  immediately  to  the 
Test  Director.  All  testing  will  be  sus¬ 
pended  to  afford  participating  Services 
an  opportunity  to  discuss  the  deficiency. 
If  all  participants  agree  that  the  test 
should  be  terminated,  the  test  will  be 
halted  until  the  deficiency  is  corrected. 
If  appropriate,  participants  may  deter¬ 
mine  that  tests  can  continue  safely  on  a 
limited  basis  pending  subsequent  correc¬ 
tion  of  the  deficiency.  If  agreement 
cannot  be  reached  concerning  the  nature 
and  magnitude  of  the  deficiency,  it  will 
be  necessary  for  the.  Test  Director  to 
consider  what  portions  of  the  test,  if 
any,  are  unaffected  by  the  deficiency 
and  can  be  continued  safely  while  the 
deficiency  is  being  corrected.  Immedi¬ 
ately  upon  making  such  a  determination, 
the  Test  Director  shall  provide  the 
OT&E  agencies  with  the  circumstances 
concerning  the  deficiency,  the  positions 
put  forth  by  the  Deputy  Test  Direc¬ 
tors),  his  decision  and  reasons  therefor. 

e.  Test  IRenortlne.  The  following 
test  reporting  policy  will  apply  for  all 
MOT&E  programs: 

(1)  Each  participating  OT&E 
agency  will  prepare  an  independent 
evaluation  report  in  its  own  formal  and 
will  process  that  report  through  its  nor¬ 
ma!  Service  channels. 

(2)  Interim  test  reports  will  nor¬ 
mally  not  be  prepared.  For  test  phases 
which  extend  for  lengthy  periods,  in¬ 
terim  test  reports  should  be  submitted  at 
least  annually.  Test  reporting  require- 
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ments  will  be  defined  in  the  TEMP. 
When  required,  interim  reports  will  be 
prepared  in  accordance  with  lead  Ser¬ 
vice’s  directives  and  coordinated  with  all 
participating  OT&E  agencies  prior  to 
release. 

(3)  For  major  programs,  the  lead 
Service  will  prepare  and  coordinate  the 
single  (interim  or  final)  report  reflecting 
the  system’s  operational  effectiveness 
and  suitability  for  each  Service.  It  will 
synthesize  the  different  operational  re¬ 
quirements  and  operational  environments 
of  the  involved  Services.  It  will  state 
findings,  put  those  findings  into  per¬ 
spective,  and  present  rationale  why  there 
is/is  not  consensus  on  the  utility  of  the 
system. 

(a)  The  participating  Services’ 
independent  evaluation  reports  will  be 
appended  to  final  reports. 

(b)  This  report  will  be  sub¬ 
mitted  to  OSD’s  Director  of  Operational 
Test  and  Evaluation  (DOT&E)  and 
OSD’s  Deputy  Under  Secretary  of  De¬ 
fense  for  Research  and  Engineering, 
Test  and  Evaluation  (DUSDRE-(T&E)) 
at  least  45  days  prior  to  a  milestone  de¬ 
cision  or  the  date  announced  for  the  fi¬ 
nal  decision  to  proceed  beyond  low  rate 
initial  production  (LRIP).  An  interim 
summary  OT&E  report  shall  be  submit¬ 
ted  if  the  formal  end  of  test  phase  re¬ 
port  is  not  available  45  days  prior  to  the 
milestone  review.  For  programs  that  do 
not  have  a  traditional  milestone  or  LRIP 
decision,  the  test  report  will  be  submit¬ 
ted  60  calendar  days  after  the  last  test 
event. 

(4)  For  those  reports  not  requir¬ 
ing  submission  to  DOT&E  and  DUS- 
DRE(T&E),  a  single  multiservice  report 
is  not  required.  The  approved  indepen¬ 
dent  evaluation  reports  will  be  dis¬ 
tributed  to  all  participating  agencies. 
These  reports  should  forwarded  to 


the  other  participating  agencies  60  cal¬ 
endar  days  after  the  last  test  event. 

(5)  The  lead  Service  OT&E 
agency  will  be  responsible  for  preparing 
the  Defense  Systems  Acquisition  Review 
Council  (DSARC)  briefing(s)  which  will 
be  coordinated  with  all  participating 
OT&E  agencies. 

4.  JOINT  TEST  &  EVALUATION. 

a.  PSB-PJrttfifcd  .Jlftfc.  Dodd 
5000.3  specifically  directs  the  Services  to 
participate  in/monitor  the  development 
of  the  JT&E  feasibility  study  and  the 
test  design  and  to  coordinate  the  results 
of  both  efforts  prior  to  commitment  of 
any  resources.  This  implies  that  the. 
Services  should  become  involved  early  in 
the  planning  phase  of  all  OSD-directed 
JT&E  programs,  to  include  active  par¬ 
ticipation  in  the  JT&E  nomination  pro¬ 
cess.  This  will  provide  the  OT&E 
agencies  an  opportunity  to  review  and 
comment  on  all  JT&E  programs.  The 
purpose  of  this  review  will  be  to  ensure 
that  the  JT&E  program  and  its  associ¬ 
ated  documentation  contain:!  the  fol¬ 
lowing  critical  information: 

(1)  Specific  definitions  of  the 

critical  issues  to  be  investigated. 

(2)  A  specific  listing  of  the  crit¬ 
ical  and  major  objectives  of  the  JT&E 
program. 

(3)  An  enemy  threat  assessment 

that  has  been  coordinated  among  the 

participating  Services  and  validated  by 
the  Defense  Intelligence  Agency  (if  ap¬ 
plicable). 

(4)  The  anticipated  impact  that 

the  JT&E  program  will  have  on  force 
readiness  and  training. 

(5)  An  estimate  of  the  total  costs 
and  an  identification  of  fund  sources. 


(6)  A  schedule  of  program  events 
which  will  permit  timely  preparation  of 
Service  documentation  and  budgeting  to 
accomplish  program  objectives, 

If,  during  review  of  JT&E  program 
documentation,  the  OT&E  Commanders 
find  that  the  above  areas  are  not  ade¬ 
quately  covered,  they  shall  mutually 
discuss  problems  and  submit  separate 
comments  to  their  respective  Service 
chiefs. 

b.  Early  Service  Involvement.  Ser¬ 
vices  will  be  responsible  for  the  conduct 
of  JT&E  feasibility  studies.  OSD  sup¬ 
port  agencies  or  independent  contractors 
may  be  utilized  by  the  Services  to  assist 
in  the  preparation  of  the  feasibility 
studies.  However,  in  all  circumstances, 
the  support  agcnts/contractors  will  be 
working  for  the  Service(s)  responsible 
for  the  feasibility  study.  Early  in  the 
feasibility  study  of  a  designated  joint 
test,  the  lead  Service  JT&E  point  of 
contact  (POC)  will  coordinate  an  ad  hoc 
planning  meeting  with  the  remaining 
Service  JT&E  POCs.  For  joint  tests  the 
initial  Service  POCs  are: 

USA  CSTE-RMD-J 
USN  OPNAV  983 
USAE  AFOTEC/JT 
USMC  MCOTEA 

Following  this  meeting,  the  Service 
POCs  will  identify  a  Service  icpresenta- 
tive  to  work  with  the  support  agent  for 
the  specific  joint  test.  Service  repre¬ 
sentatives  may  visit  with  support  agents 
independently  but  will  inform  other 
Service  representatives  of  the  meeting  in 
advance. 

c.  Test  Force  Structure.  Unless 
specific  direction  to  the  contrary  is 
given  by  the  OSD,  the  basic  joint  test 
force  structure  will  be  as  shown  in  en¬ 
closure  (4),  Service  Deputy  Test  Direc¬ 
tors  (DTDs)  arc  intended  to  be  the  se¬ 
nior  Service  representatives.  They  will 


act  as  advisors  to  the  JTD,  will  represent 
their  Service’s  interests,  and  will  be  re¬ 
sponsible  for  the  personnel  administra¬ 
tion  of  individuals  of  their  Service  who 
arc  assigned  to  the  JTD  Staff.  They  will 
be  consulted  by  the  JTD  in  resolving 
personnel  problems  involving  members 
of  their  Service,  whether  such  members 
are  assigned  to  the  Joint  Test  Force 
(JTF)  or  not.  In  executing  actions  in¬ 
tended  to  change  personnel  attached  to 
the  staff,  JTDs  will  be  guided  by  and 
conform  with  applicable  Service  direc¬ 
tives.  Since  DTDs  will  be  advisors  to 
the  JTD  and  will  represent  their  Ser¬ 
vice’s  interest,  they  will  normally  have 
reporting  chains  back  to  their  Service 
and/or  OT&E  agency  comman¬ 
der/director.  DTDs  may  also  serve  as 

functional  directors  reporting  to  the 

JTD.  The  number  of  functional  direc¬ 
tors  reporting  to  the  JTD  may  vary  with 
the  size  of  the  program.  Enclosure  (4) 
illustrates  the  preferred  separation  of 
functions.  The  joint  test  force  structure 
will  be  thoroughly  integrated;  i.e.,  there 
will  be  no  Service  test  team  identifica¬ 
tion.  OT&E  agency  commanders/dir¬ 
ectors  will  support  inclusion  of  the 

above  intent  in  all  JTD  charters. 

5.  QUADRI-SERVICE  REVIEW. 

a.  The  OT&E  Commanders  will 

confer  on  an  as- needed  basis  to  ex¬ 
change  views  on  OT&E  matters  of  mu¬ 
tual  interest. 

b.  Responsibility  for  issuing  a  call 
for  a  review  of  the  MOA  will  be  rotated 
among  the  Services,  This  call  will  be 
initiated  at  least  30  days  prior  to  the  an¬ 
niversary  date  of  the  MOA.  That  Ser¬ 
vice  also  has  the  responsibility  for  call¬ 
ing  such  meetings  as  are  required  to 
reach  agreement  on  proposed 
changes/additions  to  this  MOA,  and  will 
take  the  lead  in  publishing  change  pages 
or  republishing  the  entire  document, 

c.  Terms  of  this  understanding  be- 
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come  effective  upon  signature  by  all 
parties  and  may  be  revised  by  mutual 
consent  provided  such  changes  are  ac¬ 
complished  by  written  agreement. 


/s/JAMES  E.  DRUMMOND,  Major 
General,  USA  Commander, 
USAOTEA 

/s/MICHAEL  D.  HALL,  Major 
General,  USAF  Commander, 
AFOTEC 

/s/J.T.  PARKER,  Rear  Admiral, 
USN  COMOPTEVFOR 

/s/H.  L.  SEAY,  Colonel,  USMC 
Director,  MCOTEA 
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DUTIES  AND  RESPONSIBILITIES 
OF  PARTICIPANTS  IN  MULTISERVICE  QT&E 


Functional  Area 

L£aiLSmiri 

Supporting  Serviced 

1.  Personnel 

-Assign  the  OT&E 

Director 

-Assign  deputy  test 
directors  to  the  test 
team 

-In  conjunction 
with  the  support¬ 
ing  Service(s), 
establish  joint 
manning  require¬ 
ments 

-Establish  Service  man¬ 
ning  requirements  to 
support  the  joint  man¬ 
ning  requirements 

-Staff  the  test 
team  as  indicated 
in  the  joint  man¬ 
ning  document 

-Staff  the  test  team 
as  directed  by  the 

Service  manning 
document 

2.  Administration 

-Provide  initial 
administrative 
support  services 
until  the  formu¬ 
lation  and  staf¬ 
fing  of  the  test 
team 

-Provide  administra¬ 
tive  support  to 

Service  representa¬ 
tives  until  staf¬ 
fing  of  the  test 
team 

-Recommend  func¬ 
tional  tasks 
to  be  performed 
by  each  level  of 
the  test  team 

-Provide  administrative 
support  for  Service- 
unique  requirements 

-Provide  functional  task 
requirements  to  the  lead 
Service 

3.  Funding 

-Fund  initial 
organizational, 

rvUtinmn  nnfl 

piuniAii  »£j|  uau 

administrative 

-Fund  own  Service  TDY 
costs 

costs  except  TDY 
and  other  Service- 
unique  requirements 

-Fund  own  Service  TDY  and 
unique  requirements 

Enclosure  (1) 
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-Funding  of  test  require¬ 
ments  will  be  IAW  DOD 
and  Service  directives 


-Funding  of  test 
requirements  will 
be  IAW  DOD  and 
Service  directives 


4.  Threat 
Assessment 


5.  Resources 


-Ensure  that  a  co- 
cordinated  threat 
assessment  has  been 
developed  IAW 
lead  Service  dir¬ 
ective^),  coordi¬ 
nated  with  the  DIA, 
and  is  provided  to 
all  participants 

-Provide  an  updated 
threat  assessment  to 
each  participant 
prior  to  each  major 
program  review 

-Consolidate  total 
resource  require¬ 
ments  and  include 
same  in  basic 
program  documents 

-Indicate  Service  re- 
sonsible  for  providing 
each  resource 


-Support  lead  Service 
efforts  in  the  develop¬ 
ment  and  periodic 
update  of  the  threat 
assessment 


-Identify  for  the  lead 
Service  all  resources 
required  to  conduct 
the  test 


-Extract  Service 
resource  require¬ 
ments  from  the  basic 
documentation 


-Prepare  Service 
documents  to  support 
basic  resource 
requirements 
document 


6.  Data 

Management1 


-Ensure  that  a 
comprehensive 
data  collection/ 
plan  is  formulated 

-Designate  a  cen¬ 
tral  repository 
for  data  collected 


-Support  lead  Service 
in  preparing  the  data 
collection/management 
plan 

-Ensure  that  all  data 
collected  are  made 
available  to  the  lead 
Service  for  storage  into 
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the  central  data 
data  depository 


-Provide  ready 
access  to  the 
collected  data  to 
all  participating 
agencies 

7.  Documentation 

-Prepare  overall 
program  documen¬ 
tation  in  accord¬ 
ance  with  lead 

Service  directives 

-Provide  inputs  to  the 
basic  documents 

-Make  provisions 
for  the  attach¬ 
ment  for  Service- 
unique  documenta¬ 
tion  requirements 
as  annexes  to  the 
basic  documents 

-Provide  Service-unique 
documentation  require¬ 
ments  to  lead  Service 
as  an  annex  to  the  basic 
documentation 

-Prepare  an  inde¬ 
pendent  operational 
evaluation  report 
in  accordance  with 

Service  directives 

-Prepare  an  independent 
operational  evalu 

Otion  report  in 
accordance  with  Ser¬ 
vice  directives 

8.  Deficiency 

Reporting 

-Provide  deficiency 
reporting  pro¬ 
cedures,  formats, 
and  direction. 

Accept  deficiency 
reports  (DRs)  from 

DTDs.  Submit  DRs 
to  appropriate 
program  managers. 

Ensure  supporta- 
ing  Services  receive 
deficiency  status 
reports  periodically 

-Submit  DRs  concerning 
Service-unique  or  gen¬ 
eral  problems  with  the 
test  item  in  the  format 
prescribed  by  the  lead 
Service.  Use  lead  Ser¬ 
vice  prescribed  defini¬ 
tions,  DR  system,  and 
forms 

1.  To  tuiur*  »  progrtuiv*  evaluation  of  th«  »y«t»m,  than  will  b«  an  unraatrictad  axchanga  of  data  only  among  the 
OTi’E  agenciei  and/or  taet  taami.  Said  data  ihall  not  ba  promulgated  nr  otherwiie  allowed  to  be  shared  with  in¬ 
dividuals  or  organisation*  not  a  ilgnatory  to  thie  MOA. 
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PARTICIPANTS  IN  JOINT  TEST  AND  EVALUATIONS 


ACTIONS  NORMALLY  ACCOMPLISHED  BY  THE 
DIRECTOR  OF  OPERATIONAL  TEST  AND  EVALUATION  (DOT&EI 


Select  JT&Es  (in  coordination  with  DUSDRE(T&E)  and  the  Services). 

2.  Plan,  program,  and  budget  for  JOT&E. 

3.  Fund  test  unique  costs  for  JOT&E  (in  accordance  with  DOD  Budget  Guidance 
Manual  71 10-1-M). 

4.  Appoint  the  Lead  Service  for  JOT&E. 

5.  Review  qualifications  and  act  as  approval  authority  for  the  Lead  Service  nomina¬ 
tion  of  the  Joint  Test  Director  for  JOT&E. 

6.  Charter  JOT&E. 

7.  Designate  supporting  Service(s)  for  JOT&E. 

8.  Act  as  the  DOD  approval  authority  foi  feasibility  studies  for  JOT&Es  (in  coordi¬ 
nation  with  the  Service(s)). 

9.  Approve  test  designs  for  JOT&E  (in  coordination  with  the  Services  and  the  Joint 
Test  Directors). 

10.  Approve  field  test  plans  for  JOT&E  (in  coordination  with  the  Service  and  Joint 
Test  Directors). 

11.  Direct  an  independent  evaluation  (by  a  support  contractor)  of  JOT&E  test  results 
when  required. 

12.  Co-chair  (with  DUSDRE(T&E))  the  JT&E  Senior  Advisory  Council. 
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PAR  ’ANTS  IN  JOINT  TEST  AND  EVALUATIONS 
ACTIONS  NORMALLY  ACCOMPLISHED  BY  THE 


1.  Administer  the  nomination  process  for  proposed  JT&E. 

2.  Select  JT&Es  (in  coordination  with  DOT&E  and  the  Services). 

3.  Plan,  program  and  budget  for  JDT&E. 

4.  Fund  test-unique  costs  for  JDT&E  (in  accordance  with  DOD  Budget  Guidance 
Manual  711G-1-M). 

5.  Appoint  the  lead  service  for  JDT&E. 

6.  Review  the  qualifications  and  act  as  approval  authority  for  the  Lead  Service  nomi¬ 
nation  of  the  Joint  Test  Director  for  JDT&E. 

7.  Charter  JDT&E. 

8.  Designate  supporting  Service(s)  for  JDT&E. 

9.  Act  as  the  DOD  approval  authority  for  feasibility  studies  for  JDT&E  (in  coordina¬ 
tion  with  the  Services). 

10.  Approve  test  designs  for  JDT&E  (in  coordination  with  the  Services  and  Joint  Test 
Directors). 

11.  Approve  field  test  plans  for  JDT&E  (in  coordination  with  the  Services  a^d  Joint 
Test  Directors). 

12.  Direct  an  independent  evaluation  (by  a  support  contractor)  of  JDT&E  test  results 
when  required. 

13.  Establish  overall  policy  and  direction  (in  coordination  with  DOT&E)  for  JT&E 
programs. 

14.  Co-chair  (with  DOT&E)  the  JT&E  Senior  Advisory  Council. 


PARTICIPANTS  IN  JOINT  TEST  AND  EVALUATION 
DUTIES  AND  RESPONSIBILITIES  OF  THE 
LEAD  SERVICE  ^EXECUTIVE  AGF.NT/SERVICFT 

1.  Appoint  the  Joint  Test  Director  and  Deputy  Test  Director  in  coordination  with 
DOT&E/DUSDRE(T&E)  as  appropriate. 

2.  Provide  administrative  support  for  feasibility  studies  and  approved  JT&E. 

3.  Provide  adequate  facilities  (when  available)  for  the  JTF  located  on  an  installation 
under  control  of  the  lead  Service. 

4.  Provide  appropriate  Service  resources. 

5.  Obligate  funds  necessary  to  support  the  lead  Service’s  portion  of  the  JT&E 
(excluding  test  unique  costs  funded  by  OSD), 

6.  Support  test  planning,  execution,  evaluation,  and  reporting. 

7.  Designate  Service  units  responsible  for  providing  JT&E  support. 

8.  Participate  in  the  preparation  and  coordination  of  the  JT&E  feasibility  study  and 

test  design. 

9.  Contact  DOD’s  Joint  Test  Support  Center1  to  learn  of  any  information  which 
would  be  of  value  in  planning,  conducting,  or  reporting  ou  joint  tests.  Coordinate  with 
the  supporting  Service(s)  as  appropriate. 

10.  Review  and  coordinate  on  the  JT&E  field  test  plan. 

11.  Prepare  the  Consolidated  Resource  Estimate. 

12.  Identify  special  Service  requirements  for  data  or  special  test  events  which  may  be 
incorporated  into  the  test. 

13.  Provide,  fully  qualified  personnel  to  the  JTF. 

14.  Designate  a  unit  or  agency  within  the  Service  responsible  for  Service  coordination. 

15.  Designate  a  by  name  point  of  contact  for  each  specific  JT&E. 

16.  Issue  a  Service  test  directive. 

17.  Procure  and/or  modify  test  items,  systems,  equipment,  and  instrumentation  as  re¬ 
quested  by  the  JTD  and  coordinated  by  the  Service  (costs  funded  by  OSD). 

18.  Conduct  an  independent  evaluation  of  the  test,  if  desired. 
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19.  Review  final  test  report. 

20.  Provide  a  permanent  member  to  the  JT&E  Senior  Advisory  Council. 

21.  Provide  a  permanent  member  to  the  OSD  JT&E  Planning  Committee. 

NOTE: 

1.  DoD  Joint  T«»t  Support  Ctnt«r,  1517  Wotbranch  Drivt,  McLean,  VA  22102,  (70S)  827-9300. 
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PARTICIPANTS  IN  JOINT  TEST  AND  EVALUATIONS 


DUTIES  AND  RESPONSIBILITIES  OF  THE 

SVPPQFTING  SERVICES 

Appoint  the  Deputy  Test  Director  in  coordination  with  DOT&E/DUSRE(T&E). 

2.  Provide  adequate  facilities  (when  available)  for  the  JTF  located  on  an  installation 
under  control  of  the  supporting  Service. 

3.  Provide  appropriate  Service  resources. 

4.  Obligate  funds  necessary  to  support  the  supporting  Service’s  portion  of  the  JT&E 
(excluding  test  unique  costs  funded  by  OSD). 

5.  Support  test  planning,  execution,  evaluation,  and  reporting. 

6.  Designate  Services’  units  responsible  for  providing  JT&E  support. 

7.  Participate  in  the  preparation  and  coordination  of  the  JT&E  feasibility  study  and 
test  design. 

8.  Review  and  coordinate  on  the  JT&E  field  test  plan. 

9.  Participate  in  the  preparation  of  the  Consolidated  Resource  Estimate. 

10.  Identify  special  Service  requirements  for  data  or  special  test  events  to  be  incorpo¬ 
rated  into  the  test. 

11.  Provide  fully  qualified  personnel  to  the  JTF. 

12.  Designate  an  individual  or  agency  within  the  Service  responsible  for  Service  coor¬ 
dination. 

13.  Designate  a  by  name  point  of  contact  for  each  specific  JT&E. 

14.  Issue  a  Service  Test  Directive. 

15.  Procure  and/or  modify  test  items,  systems,  equipment,  and  instrumentation  as  re¬ 
quested  by  the  JTD  and  coordinated  by  the  Service  (costs  funded  by  OSD). 

16.  Conduct  an  independent  evaluation  of  the  test,  if  desired. 

17.  Review  final  test  report. 

18.  Provide  a  permanent  member  to  the  JT&E  Senior  Advisory  Council. 

19.  Provide  a  permanent  member  to  the  OSD  JT&E  Planning  Committee. 
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FOR  COMPLEX  PROGRAMS  WITH  MANY  PARTICIPANTS 


SAMPLE 

DEFICIENCY  ANALYSIS  SHEET  (DAS) 

DAS  NUMBER 

!  SYSTEM 

PRIORITY 

TITLE: 

ppp/fpp  NO 

WORK  PACKAGE 

RFI  ATl-D  DAS  NO  (S) 

MODULES  AFFFPTFD 

Soiirpf 

DATF  . 

ACTION  .  _ 

DATE  ... 

CORRECTED 

DATE 

_  J 

STATEMENT  OF  PROBLEM 

OPERATIONAL  IMPACT  (BY 

EACH  PARTICIPATING  SERVICE) 

RELATED  SYSTEMS  IMPACT 

SAMPLE 

DEFICIENCY  ANALYSIS  SHEET  (DAS) 


ENCLOSURE  (5) 
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STATUS 

U. 

AC-ACTIVE,  PE-PENDING 

CL-CLOSED 

B 

DEPOT  REPAIR/REPLACE,  TAPE  PATCH  DUE  BY  24  AUG  78, 
SEE  ECP  NX.009,  ETC. 

0  u. 

C  UJ 

G  <*: 

FH-MS-004,  L59201 ,  ESD  LTR  18  MAR  79 

CLOSURE 

CODE 

a 

NEEDHAM,  FORT  HUACHUCA,  ETC. 

COG. 

AGENCY 

u 

GTE,  MSCS,  ESD,  RCA,  ETC. 

| 

SHORT  TITLE,  PART  NO..  SUBASSEMBLY,  ETC. 

PLUS  PROGRAM 

EXAMPLES: 

1.  OX-54  INVERTERS  FAILED 

2.  SOFTWARE  PLT-B  (E7R31 )  (DIAG) 

TIMING  PROBLEM  WHEN  TTY  ON  LINE 

3.  VDU  B  CARD  FAILURE 

gS 

C  U. 

*"S 

CO 

INFO,  MINOR  INC,  OPERATIONAL,  ETC. 

REPORT 

DATE 

1 

^  cj 

K 

B 

EPRKH-61, 11-23001 -YC-2Q-  T,  ETC. 

1 

AN/TYC-39,  CNCE.  ETC. 
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SAMPLE 

DEFICIENCY  REPORT  SUMMARY  ENCLOSURE  (6) 
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1.  Test  Title 

2.  References 

3.  Purpose  cf  test 

4.  Scope  and  Tactical  Content 

5.  Test  Objective 

6.  Lead/Participating  Services 

7.  Services  POC  Lists 

8.  Test  Installation  Locations 

9.  Test  Dates 

10.  Joint  Test  Directorate  Personnel/Equipment 

a.  Joint  Test  Staff 

(1)  Data  Management 

(2)  Logistical 

(3}  Administrative 

(4)  Test  Operations 

(5)  Controllers 

(6)  Data  Collectors 

b.  Aviation  Support 


Signal/Communications 
Miscellaneous  Equipment 
Training  Requirements 
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11.  Player  Participants  Personnel/Equipment 


a.  Blue  Force 

(1)  Ground  Players/Units 

(2)  Aviation  Players/Units 

(3)  Ground  Players  Equipment 

(4)  Aircraft  Hours/Types 

(5)  Training  Requirements 

b.  Red  Force 

(1)  Ground  Players/Units 

(2)  Aviation  Players/Uniis 

(3)  Ground  Players  Equipment 

(4)  Aircraft  Hours/Types 

(5)  Training  Requirements 

12.  Installation  Support 

13.  Simulators/Surrogates 

14.  Instrumentation 

15.  ADP 

16.  Ammunition/Missiles 

17.  POL 

18.  Contractor  Support 

19.  Funding  Estimates 

20.  Milestones 


Page  2  of  Enclosure  (7) 


1L 


mMHSVMVl 


.  w*'  W yv  VW»  w  v>  wv  iif  tfv w  yv  uwvuv v> w* w  yv \rw yy  .r*  ut»  vnk-»  k>tfKu-nv« 


w 


APPENDIX  D 

INSTRUCTIONS  FOR  THE  PREPARATION  OF  JOINT 
INTEGRATED  LOGISTICS  SUPPORT  PLANS 

(JILSP)1 


1.  HOW  TO  PREPARE  AND  USE 
THE  JILSP: 

a.  Preparation  of  the  JILSP  should 
be  the  responsibility  of  the  executive 
service.  Participating  services  should 
provide  a  central  point  of  contact  for 
coordination  of  the  plan  in  their  service. 

b.  The  JILSP  begins  as  a  broad, 
objective-oriented  document  in  the 
conceptual  phase  and  becomes  a  more 
specific  tasking  and  milestone  schedul¬ 
ing  document  as  a  program  progresses 
through  the  acquisition  process.  The 
JILSP  should  be  tailored  to  the  charac¬ 
teristics,  needs,  and  complexity  of  each 
program  and  official  program  direction. 

c.  In  preparing  the  JILSP,  empha¬ 
size  the  specific  tasks  to  be  accom¬ 
plished,  who  is  responsible  for  the  tasks, 
and  the  schedule  for  joint  tasks.  Brevity 
is  essential;  make  all  entries  clear  and 
concise.  Keep  narrative  material  to  a 
minimum,  Do  not  repeat  information 
from  other  documents,  unless  it  is 
needed  to  understand  the  JILSP.  In 
tailoring  the  JILSP  to  the  individual 
program,  be  innovative  to  accommodate 
unique  program  features  consistent  with 
comprehensive  ILS  planning. 

d.  Begin  developing  the  JILSP  du¬ 
ring  the  conceptual  phase  of  a  program 
as  part  of  the  acquisition  strategy. 
Guidance  for  preparation  of  the  JILSP  is 
included  in  paragraph  3. 

e.  Coordinate  the  JILSP  with  ail 
participating  and  affected  organizations. 
When  signed  by  the  PM,  the  JILSP  be¬ 
comes  the  ILS  implementation  plan  that 
all  participating  activities  must  comply 
with. 


f.  Develop  the  JILSP  so  it  can  be 
used  as  a  daily  "working  document"  by 
working  level  personnel. 

(1)  Part  1  (General)  and  Part  II 
(Concept/Strategy)  contain  all  narrative 
portions  of  the  plan.  Narratives  are  not 
needed  for  any  ILS  function  for  which  a 
milestone  schedule  chart  is  developed. 
While  some  general  information  may  be 
necessary,  those  features  and  innovative 
techniques  that  are  unique  to  the  system 
must  be  identified.  The  narrative  por¬ 
tion  of  the  plan  will  be  constructed  so 
that  changes  are  only  required  when  ba¬ 
sic  objectives,  concepts,  or  criteria  are 
modified, 

(2)  Part  III  of  the  JILSP  is  made 
up  of  individual  milestone  charts  that 
can  be  easily  updated  to  show  program 
status  and  to  identify  the  interfaces 
where  a  change  to  a  specific  task  affects 
another  task(s)  within  any  milestone 
schedule  chart.  When  a  computer-sup¬ 
ported  program  management  information 
system  is  used  to  reflect  program  status, 
consider  using  the  computer  system  out¬ 
put  products  as  Part  III  of  the  JILSP. 
Exercise  caution  to  ensure  that  the  out¬ 
puts  used  are  clear  and  complete 
enough,  can  be  easily  understood  by  re¬ 
viewers  and  users  of  the  JILSP  without 
extensive  study. 

g.  Services  differences  in  ILS  plan¬ 
ning  should  be  incorporated  into  the 
basic  JILSP  as  an  integral  part  or  the 
planning  process  for  the  individual  ele¬ 
ments. 

2.  JILSP  REVIEWS. 

Review  and  update  the  JILSP  when¬ 
ever  new  program  direction  is  received 
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or  changes  occur  that  warrant  realign¬ 
ment  of  logistics  support  planning. 
Keep  a  log  of  the  last  time  each  page 
was  reviewed  and  updated. 

3.  JILSP  FORMAT: 

a.  Part  I  -  General 

(t)  System  Description  -  Briefly 
describe  the  system  and  equipment,  its 
purpose,  and  general  performance  char¬ 
acteristics. 

(2)  Program  Management  -  Iden¬ 
tify  all  participating  organizations  and 
whether  it  is  applicable  to  security  as¬ 
sistance  programs. 

(3)  Applicable  Documents  -  Iden¬ 
tify  those  documents  that  provide 
guidance  or  criteria  necessary  to  accom¬ 
plish  functions  described  in  the  JILSP. 

b.  Part  ll  -  Concepts/  Strategy: 

(I)  Operations  Concept  -  Briefly 
describe  the  operational  concept  in  terms 
of  mission  scenarios,  operational  envi¬ 
ronment,  employment  concepts,  and  de¬ 
ployment  plans.  Provide  sufficient  de¬ 
tail  (annual  operating  days,  annual  num¬ 
ber  of  missions,  mean  mission  duration, 
etc.)  to  provide  input  to  the  LSA  pro¬ 
cess. 


(2)  Maintenance  Concept  -  Briefly 
describe  maintenance  requirements, 
considerations,  and  constraints  in  terms 
of  number  of  skill  level  of  maintenance 
personnel,  number  of  inventory  items, 
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maintenance,  operational  reliability  and 
survivability  requirements,  failure  diag¬ 
nostic  techniques,  support  equipment, 
and  any  maintenance  considerations 
peculiar  to  the  system.  Identify  any 
maintenance  concept  tradeoffs  to  be 
performed.  Provide  sufficient  detail 
(turn-around  time,  mean  time  between 
maintenance,  mean  time  to  repair,  etc.) 


to  support  LSA,  data  requirements,  in¬ 
terim  contractor  support,  and  contractor 
logistics  support. 

(3)  Logistics  Support  Analysis  - 
Describe  the  LSA  program.  Include  a 
brief  description  of  LSA  tasks  required, 
the  structure  of  the  LSA  data  system 
and  contractor-government  interrela¬ 
tionships  in  the  conduct  of  LSA. 

(4)  Acquisition  Strategy  -  Briefly 
describe  the  procurement  approach  and 
define  new  or  innovative  contractual 
approaches  for  life  cycle  costs,  logistics 
support  costs,  reliability  improvement 
warranties  (RIW),  spares  acquisition  in¬ 
tegrated  with  production  concept,  and 
interim  contractor  support.  Also,  de¬ 
scribe  budget  and  funding  policies  that 
are  in  addition  to,  or  deviate  from, 
standard  procedures,  etc. 

(5)  Test  and  Evaluation  Concept  - 
Briefly  describe  the  test  and  evaluation 
concept  in  terms  of  DT&E,  OT&E,  par¬ 
ticipating  organizations  (including  con¬ 
tractor),  and  management  relationships. 
Include  information  on  peculiar  test  re¬ 
quirements  that  are  directly  related  to 
the  ILS  program  (that  is,  reliability, 
maintainability,  supportability,  or  con¬ 
tractual  requirements  related  to  a  sup¬ 
port  cost  guarantee  or  RIW).  Address 
the  interface  between  the  LSA  data  sys¬ 
tem  and  the  test  program. 

( 6)  Other  Concepts  -  Briefly  de¬ 
scribe  unique  or  innovative  support 
concepts  established  or  required  to  pro¬ 
vide  effective  logistics  support.  Do  not 
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to  show  the  interface  or  rationale  for  the 
new  concept.  Briefly  describe  any  pe¬ 
culiar  aspects  of  the  system,  such  as 
survivability  considerations,  technical 
data,  support  equipment,  etc.  Trans¬ 
portation  and  packaging  concepts  may 
be  added,  to  describe  unique  require¬ 
ments  for  protection  and  movement  of 
system  and  equipment. 
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c.  Part  III 
Chans  (MSC): 


Milestone  Schedule 


(1)  Use  these  charts  to  address 
specific  ILS  functions  and  to  show  the 
anticipated  beginning  and  completion 
dates  for  each  task  and  event,  the  as¬ 
signed  OPR,  and  the  applicable  resource 
requirements  (as  a  minimum,  identify 
OPRs  by  the  three-letter  office  symbol). 

(2)  Use  resource  requirements  to 
represent  commitments  agreed  to  by  the 
participants. 

(3)  Coordinate  the  ILS  milestones 
with  all  organizations  involved,  to  en¬ 
sure  that  tasks  and  events  are  complete, 
accurate,  integrated  with  contractual  re¬ 
quirements,  and  related  to  key  "program" 
milestones. 

(4)  Do  not  include  narrative  in 
Part  III  of  the  JILSP. 

(5)  Set  up  the  first  MSC  during 
the  conceptual  phase.  During  the  Full- 
Scale  Engineering  Development  (FSED), 
expand  the  MSC  to  include  detailed 
tasks,  icsponsibili'ies,  and  schedules  for 
providing  logistics  support  for  the  sys¬ 
tem  or  equipment. 

(6)  Delegate  the  responsibility  for 
maintaining  current  status  ot  the  MSC  to 
working  level  people  in  each  ILS  func¬ 
tional  area.  1'his  includes  tracking  tasks 
and  events,  as  well  as  reporting  progress. 

(7)  Set  up  procedures  to  ensure 
that  it  becomes  apparent  that  a  mile¬ 
stone  will  not  be  met  or  when  new  pro¬ 
gram  direction  or  guidance  impacts  the 
functional  area. 

(8)  Set  up  and  maintain  manage¬ 
ment  visibility  of  all  hardware,  down  to 
and  including  all  recoverable  assemblies. 

(9)  MSCs  should  normally  be 


prepared  for  each  of  the  functional  ar¬ 
eas  identified  below,  although  MSCs  for 
a  specific  program  or  project  can  be 
tailored  by  the  ILSO,  as  approved  by  the 
PM.  MSCs  for  the  ILS  elements  should 
be  developed  using  network  analysis. 
Representative  examples  of  the  types  of 
tasks  and  events  that  should  be  consid¬ 
ered  for  tracking  through  MSCs  are 
listed  following  each  subparagraph 
heading.  Individual  MSCs  must  reflect 
the  support  to  be  provided  by  all  par¬ 
ticipating  services  and  agencies. 

(a)  Design  Interface  ( Dl )  - 
Identify  milestones  for  key  program 
events  where  logistics-related  design 
parameters  are  established,  assessed,  or 
modified,  such  as  specification  ap¬ 
provals,  design  reviews,  audits,  test  and 
evaluation,  demonstrations,  configura¬ 
tion  control  boards,  etc.  Identify  logis¬ 
tics-related  design  parameters  for  each 
DI  functional  area  (such  as  R&M)  and 
define  detailed  planning  and  implemen¬ 
tation  actions  required  to  ensure  re¬ 
quirements  are  achieved.  Examples  of 
planning  implementation  actions  include: 

(1)  Develop  supportability 
requirements  for  the  initial  and  ap¬ 
proved  R&M  program  plan,  establish 
design  guidelines  (derating,  R&M  pa¬ 
rameter  allocations,  built-in  test,  etc.); 
conduct  tradeoffs  relative  to  readiness- 
related  requirements  and  new  technology 
opportunities;  establish  initial  or  updated 
predictions  of  operational  readiness-re¬ 
lated  parameters;  determine  the  period 
covered  by  the  failure  reporting  and 
analysis;  establish  the  period  of  active 
reliability  growth  or  test  analyze  and 
fix;  develop  initial  or  approved  require¬ 
ments  verification  plan;  determine  re¬ 
quirements  verification  period(s);  estab¬ 
lish  initial  or  approved  production  cri¬ 
teria,  etc. 

(2)  Develop  and  document 
a  lifecycle  survivability  program  in¬ 
cluding  procedures  and  schedules  for 
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updating  hardware  documentation.  In¬ 
clude  plan  to  ensure  that  hardness  of  the 
system  can  be  maintained  throughout  the 
system  lifecycle. 

(3)  Develop  an  energy 
management  plan;  conduct  tradeoff 
studies  and  analysis;  develop  energy 
conservation  goals;  perform  modifica¬ 
tion;  etc. 


(4)  Identify  special  power 
generation  requirements  and  related 
cooling  requirements. 

(b)  Maintenance  Planning 
Attain  required  maintenance  capability 
for  organizational  and  intermediate  re¬ 
pair;  do  the  depot  maintenance  source  of 
repair  decision  tree  analysis  and  inter¬ 
service  screening;  establish  depot  main¬ 
tenance  capability;  identify  requirements 
for  interim  contractor  support;  identify 
facilities  and  training  requirements;  en¬ 
sure  that  provisions  are  made  for  sur¬ 
vivability,  corrosion  prevention,  spec- 
trometric  oil  analysis,  nondestructive 
inspection,  structural  integrity,  built-in 
test  equipment,  built-in  test  and  per¬ 
formance  monitoring,  and  maintenance 
activation  planning,  etc. 

(c)  Support  Equipment  -  Iden¬ 
tify,  program,  and  deliver  preoperational 
support  equipment  (SE);  conduct  SE 
guidance  conference;  set  up  require¬ 
ments  for  SE,  software,  rights  in  data 
and  computer  resources,  data,  and  doc¬ 
umentation;  review  SE  recommendations 
data  (SERDS);  identify,  quantify,  and 
program  all  operational  SE;  acquire  and 
deliver  SE  on  contract;  identify,  quan¬ 
tify,  and  program  or  acquire  all  logistics 
support  elements  needed  to  maintain  the 
SE  (spares,  technical  data,  calibration 
requirements,  etc.). 

(d)  Supply  Support  -  Identify 
and  program  spares  required  for  preop¬ 
erational  support;  program  disposition  of 
residual  preoperational  assets;  set  up 
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provisioning  plans;  identify  requirements 
for  interim  contractor  support;  deter¬ 
mine  requirements  for  and  conduct  pro¬ 
visioning  guidance  conference;  identify 
long  leadtime  items;  identify,  quantify, 
and  program  availability  of  spare  and 
repair  parts;  etc. 

(e)  Packaging.  Handling,  and 
Transportation  -  Set  up  packaging,  han¬ 
dling,  and  transportation  concepts  and 
criteria;  identify  packaging,  handling, 
and  transportation  supply  requirements; 
review  transportability  reports’  review 
and  evaluate  data  processed  through  the 
Container  Design  Retrieval  System;  de¬ 
velop  transportation  plan;  review  de¬ 
tailed  packaging  data;  develop  test  sup¬ 
port  criteria;  identify  storage  needs  for 
hazardous  materials,  conventional  muni¬ 
tions,  etc. 

(f)  Technical  Data  -  Prepare 
an  engineering  data  management  plan; 
define  the  engineering  data  required  for 
specific  organic  functions;  identify  the 
tasks  to  be  done  during  each  program 
phase;  set  up  plans  and  schedules  for  in- 
process  reviews  of  engineering  data; 
identify  review  team  composition  and 
responsibilities;  conduct  reviews;  set  up 
schedules  for  delivery  of  engineering 
data;  prepare  technical  order  publication 
plan;  identify  requirements  for  prelimi¬ 
nary  manuals,  for  operation  and  mainte¬ 
nance  of  all  systems  and  equipments; 
prepare  validation  and  verification  plans; 
verify  and  validate  technical  orders; 
print  and  send  out  technical  orders;  etc. 

(g)  Facilities  -  Prepare  facility 
requirements  plan;  conduct  surveys  to 
determine  requirements  for  new  or 
modified  preoperational,  operational, 
training,  depot,  or  simulator  facilities; 
budget  for  and  construct  facilities,  etc. 

(h)  Manpower  Requirements 
and  Personnel  -  Insert  a  matrix  of 
quantitative  requirements  for  each  func¬ 
tion  established  for  operation,  supply, 


D-4 


and  maintenance  of  thi;  equipment,  the 
personnel  skill  code  (MOS/AFSC/NEC) 
and  the  job  title  required.  Include 
whether  military,  government,  civilian, 
or  contractor;  plan  for  opera¬ 
tions/support  commands  to  acquire  per¬ 
sonnel. 

( ij  Training  and  Training 
Support  -  Initiate  eminent  and  con¬ 
nector  training;  coi.  .uct  follow-on  crew 
and  logistics  support  personnel  training; 
identify,  quantify,  and  program  all  re¬ 
quired  crew  and  maintenance  training 
equipment,  including  simulators,  as  well 
as  the  logistics  support  elements  re¬ 
quired. 

(j)  Computer  Resources  Sup¬ 
port  -  Deliver  computer  resources  devel- 
cpmen'  plan;  review  computer  program 
confirmation  item  (CPCI)  requirements, 
determine  software  needs,  to  meet  sys¬ 
tem  R&M  requirements;  deliver  Part  I 
specification;  form  a  CRWG;  publish  the 
CRISP;  etc.  NOTE:  This  entry  is 
deleted  after  uublication  of  the  CRISP 
and  a  ac.y- reference  to  the  CRISP  is 
entered  h»rewi. 

(k)  Modification  Planning 
Document  modification  and  kit  proofing 
requirements;  set  up  kit  production  rates 
comp;u;?-'‘  with  proposed  modification 
sch‘  ~ .;  send  modification  proposal 
am.^tis;  coordinate  with  the  proper 
support  activity  "  id  configuration  con¬ 
trol  boa.d  representative;  implement 
mndific-jii-jn  schedule;  evaluate  effec¬ 
tiveness  of  modifications,  etc, 

(l)  Special  Considerations 
Set  up  requirements  for  contractor  op¬ 
erations  and  support  cost  e.iimates  and 
reporting:  identify  security  assistance 
program  requirer  ents  and  site  and  depot 
activations;  set  up  specific  tradc-otfs  to 
be  carried  out  by  the  contractor;  set  up 
requirements  fot  the  contractor  to  iden¬ 
tify  and  submit  ti  -  supply  Support  plan, 
before  the  test;  develop  contractual  re¬ 


quirements  for  support  cost  guarantee  or 
RIW;  develop  a  plan  for  assessing  the 
accomplishment  of  hardware  and  sup¬ 
port  system  goals;  develop  a  verification 
and  improvement  program,  site  and  de¬ 
pot  activation,  deficiency  reporting  (for 
example,  specific  routing  and  action 
channels  for  improvement  or  deficiency 
correction,  material  deficiency  report¬ 
ing),  and  other  special  considerations  not 
included  in  one  of  the  above  categories. 

FOOTNOTE: 

1.  Appendix  D  wai  prepared  oy  Mr.  John  S.  W. 
Fargher.Jr.,  Profeseor  of  Acquieilion/Program  Man¬ 
agement,  Research  Directorate,  DSMC,  Fort 
Belvoir,  VA,  June  1982. 
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APPENDIX  E 

DEFINITION  OF  TERMS 


Most  terms  applicable  to  single  service  acquisition  management  are  also  applicable  to 
joint  service  acquisition  management.  The  glossary  included  in,  "The  Program  Manager’s 
Notebook,"  (prepared  and  published  by  the  Defense  Systems  Management  College 
(DSMC),  October  1985)  contains  an  extensive  listing  of  acquisition  management  terms 
and  their  definitions.  Accordingly,  this  appendix  only  contains  terms  and  definitions 
which  are  either  applicable  only  to  joint  programs,  or  other  relevant  terms  that  were  not 
included  in  the  glossary  cited  above. 


ACQUISITION/M  ANUFACTU  RING 
STRATEGY 

The  approach  to  obtaining  the  total 
quantity  of  a  system  at  some  rate  for 
some  cost. 

ACQUISITION  STREAMLINING 

Any  action  that  results  in  more  efficient 
and  effective  use  of  resources  to  develop , 
produce,  and  deploy  quality  defense 
systems  and  products.  This  includes 
ensuring  that  only  cost-effective  re¬ 
quirements  are  included,  at  the  most  ap¬ 
propriate  time,  in  system  and  equipment 
solicitations  and  contracts. 

APPLICATION 

The  process  of  selecting  requirements 
that  are  pertinent  and  cost  effective  for 
the  particular  material  acquisition  and 
contractually  invoking  them  at  the  most 
advantageous  times  in  the  acquisition 
cycle. 

BASELINE  COMPARISON  SYSTF* 
(BCS) 

A  current  operational  system,  or  a  com¬ 
posite  of  current  operational  subsystems, 
which  most  closely  represents  /'he  design, 
operational,  and  support  characteristics 
of  the  new  system  under  development. 

BASELINING 

A  pro/  ess  whereby  all  managers  con¬ 
cerned  collectively  agree  on  the  specific 
description  of  the  program,  requirements, 
u/id  funding,  and  make  a  commitment  to 
manage  the  program  along  those  guide¬ 
lines. 


COMPARABILITY  ANALYSIS 

An  examination  of  two  or  more  systems 
and  their  relationships  to  discover  re¬ 
semblances  or  differences. 

CONTRACT  REQUIREMENTS 

In  addition  to  specified  performance 
requirements,  contract  requirements  in¬ 
clude  those  defined  in  the  Statement  of 
Work  (SOW);  specifications,  standards 
and  related  documents;  the  Contract 
Data  Requirements  List  (CDRL):  man¬ 
agement  systems;  and  contract  terms  and 
conditions. 

CONSTRAINTS 

Restrictions  or  boundary  conditions  that 
impact  overall  capability ,  priority,  and 
resources  in  system  acquis’t’on. 

COST  CAP 

The  maximum  total  dollar  amount  the 
Department  of  Defense  is  willing  to 
commit  for  acquiring  a  given  capability. 
A  cost  cap  consists  of  program  acquisi¬ 
tion  costs  only  and  is  maintained  in  con¬ 
stant  dollars.  Cost  caps  are  applied  to 
selected  baseline  programs. 

DEFENSE  ACQUISITION  BOARD 

(DAB) 

The  Defense  Acquisition  Board  (DAB) 
was  established  in  the  early  part  of  1987 
to  replace  the  Joint  Requirements  and 
Management  Board  (JRM”)  and  its  pre¬ 
decessor,  the  Defense  systems  Acquisi- 
t.on  Review  Council  (DSARC).  The 
DAB.  like  the  JRMB  and  the  DSARC,  is 
responsible  for  reviewing  major  acquisi¬ 
tion  programs  at  designated  milestones 
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and  appraising  the  Secretary  of  Defense 
of  the  program  status  and  readiness  to 
proceed  to  the  next  phase  in  the  acquisi¬ 
tion  process,  as  well  as  other  issues  de¬ 
termined  to  be  necessary.  The  Under 
Secretary  of  Defense  ( Acquisition ) 
USD(A)  chairs  the  DAB.  Currently,  a 
DAB  Charter  is  being  staffed  that  will 
delineate  its  responsibilities  more  defi¬ 
nitely. 

DESIGN  INTERFACE 

The  relationship  of  logistics-related  de¬ 
sign  parameters,  such  as  R&M,  to  readi¬ 
ness  and  support  resource  requirements. 
These  logistics-related  design  parame¬ 
ters  are  expressed  in  operational  terms 
rather  than  as  inherent  values  and 
specifically  relate  to  system  readiness 
objectives  and  support  costs  of  the  ma¬ 
teriel  system,  one  of  the  principal  ele¬ 
ments  of  ILS. 

DESIGN  TO  GOALS 

Desirable  design  parameters  for  a  sys¬ 
tem. 

EVALUATION  CRITERIA 

Standards  by  which  achievement  of  re¬ 
quired  operational  effectiveness/  suit¬ 
ability  characteristics,  or  resolution  of 
technical  or  operational  issues,  may  be 
judged.  At  Milestone  ll  and  beyond, 
evaluation  criteria  must  include  quantita¬ 
tive  goals  (the  desired  value)  and 
thresholds  (the  value  beyond  which  the 
characteristic  is  unsatisfactory.) 

EXECUTIVE  SERVICE 
See  Lead  Service 

FAST  TRACK  PROGRAM 
An  acquisition  program  in  which  time 
constraints  require  the  design,  develop¬ 
ment,  production,  testing,  and  support 
acquisition  processes  to  be  compressed  or 
overlapped. 

FUNDING  PROFILE 

A  tabulation  of  R&D  and  Production 
dollars  using  a  span  of  years  and  several 


criteria  to  establish  a  financial  picture  of 
the  program. 

JOINT  ACQUISITION  PROGRAM 

A  directed  joint  effort  for  the  develop¬ 
ment  and  procurement  of  systems,  sub¬ 
systems.  equipment,  software,  or  muni¬ 
tions  as  well  as  supporting  equipment  or 
systems,  with  the  goal  of  providing  a 
new  or  improved  capability  for  a  vali¬ 
dated  joint  need.  Certain  modification 
programs  may  be  included  when  they  are 
determined  to  be  of  significant  interest 
or  priority  to  the  participating  services. 
( Also  see  Joint  Program.) 

JOINT  INTEGRATED  LOGISTICS 
SUPPORT  PLANS  (JILSP) 

A  program  document,  prepared  by  the 
lead  service  in  coordination  with  the 
participating  services,  is  objective- 
oriented  at  the  start  and  gradually 
becomes  task-  and  schedule- specific  as 
the  acquisition  process  gains  momentum. 

JOINT  OPERATING  PROCEDURES 
(JOPs) 

These  documents  should  identify  and 
describe  detailed  procedures  and  inter¬ 
actions  necessary  to  carry  out  significant 
aspects  of  a  joint  program.  Subjects  for 
JOPs  may  include  Systems  Engineering, 
Personnel  Staffing.  Reliability,  Surviv¬ 
ability,  Vulnerability,  Maintainability, 
Production,  Management  Controls  and 
Reporting  (including  SAR),  Financial 
Control,  Test  and  Evaluation,  Training, 
Logistics  Support,  Procurement  and  De¬ 
ployment.  The  JOPs  are  developed  and 
negotiated  by  the  Program  Manager  and 
the  participating  Services. 

JOINT  PROGRAM 

A  joint  program  is  one  in  which  two  or 
more  services  are  participating  in  the 
development  and  acquisition  of  a  weapon 
system.  In  such  a  program,  the  services 
may  ultimately  buy  the  same  item  or 
variants  of  an  item  to  reflect  service- 
specific  needs,  missions,  and  require¬ 
ments. 
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JOINT  PROGRAM  CHARTER/  PRO¬ 
GRAM  MANAGER’S  CHARTER 

A  formal  document  prepared  by  the  lead 
service  through  negotiations  and  approval 
of  the  participating  services  which  de¬ 
lineates  the  Program  Manager’s  mission 
responsibility,  authority  and  major  func¬ 
tions,  and  describes  his  relationships  with 
other  organizations  which  will  use 
and/or  support  the  Program.  The 
Charter  describes  and  assigns  responsi¬ 
bility  for  satisfying  peculiar  management 
requirements  of  participating  services 
which  are  to  be  met  in  the  program,  and 
will  be  jointly  approved  for  the  head¬ 
quarters  of  each  involved  service  by  per¬ 
sons  officially  appointed  to  approve  such 
Charters. 

JOINT  REQUIREMENTS  OVERSIGHT 
COUNCIL  (JROC) 

The  Joint  Requirements  Oversight  Coun¬ 
cil  (JROC)  was  chartered  in  1984.  Un¬ 
der  the  direction  of  the  Joint  Chiefs  of 
Staff  (JCS),  the  JROC  is  tasked  with: 
examining  potential  joint  military  re¬ 
quirements;  identifying,  evaluating,  and 
selecting  candidates  for  joint  develop¬ 
ment  and  acquisition  programs;  provid¬ 
ing  oversight  of  cross-service  require¬ 
ments  and  management  issues;  and  re¬ 
solving  service  issues  that  arise  after  a 
joint  program  has  b<  •mtiated. 

JOINT  SERVICES  OPERATIC  AI 
REQUIREMENT  (JROi  J 

A  document  that  describes  th<  th<  cut  vu! 
nerability  and  technical  r<  ■rcmctiis  of 
a  s»  stem. 

LEAD  SERVICE 

The  service  that  i~  de  gnat.. t  to  asst  'i, 
the  authority  and  sponsibuity  jo>  nu  i- 
aging  the  joint  program  by  assigning  a 
•rug ram  manager  initiating  th<  program 
i  harp  r,  and  t ah  us  the  principa 
‘ootdinator  of  mi..  t vice  relationships. 
I  Same  as  Fxrmnn.1  Service.) 

MAJOR  SVSI I  M/l'KOGKAM 


A  system/ program  that  meets  one  of  the 
following  criteria  for  jointness :  is  a 
SAR  program;  of  significant  interest  to 
OSD  or  Congress;  an  RDT&E  program 
that  is  greater  than  S 200  million  and  has 
all  its  components;  or  has  procurement 
cc"t  dollars  greater  than  $1  billion  (both 
in  FY80  dollars),  and  also  has  all  its 
components.  The  Executive  Secretary  of 
the  DAB  periodically  updates  and  dis¬ 
tributes  a  list  of  currently  designated 
OSD  major  system  acquisition  programs. 

MEMORANDUM  OF  AGREEMENT 
(MOA) 

An  agreement  between  Services  specify¬ 
ing  commitments,  responsibilities  and 
mutual  objectives.  In  the  context  of 
joint  program  such  agreements  address  a 
variety  of  critical  programmatic  issues 
such  as  management  practices,  cost 
sharing  arrangements,  etc. 

MEMORANDUM  OF  UNDERSTAND¬ 
ING  (MOU) 

An  agreement  usually  among  nations  very 
similar  in  purpose  to  Memorandum  of 
Agreement  (MOA),  A  Memorandum  of 
Understanding  may  express  a  mutual 
understanding  of  an  issue  without  im¬ 
plying  commitments  by  parties  to  the  un- 
derstu  tding. 

MULTISERVICE  CHARTER/  PRQ- 
GRA)  *  MANAGER’S  CHARTER 
See  Joint  Program  Charter/ Program 
Manager's  Charter. 

navy  program  dec.jion  meet¬ 
ing  NPDM) 

The  Navy  Progran.  De,  tsion  Meeting 
( NPDS.  1  has  been  established  by  the 
Navy  and  has  the  same  responsibilities, 
functions  and  tasks  as  its  predecessor. 
1...  Department  of  the  Navy  Systems 
Acquisition  Review  Council  (DNSARC). 

NON-!*  .AJOR  SYSTEM 

A  full  sy.tem  that  does  net  qualify  as  a 
major  system,  or  pet  forms  a  major 
function  of  a  compu  te  system  that  is  ci- 
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thcr  within  a  major  or  another  non-ma¬ 
jor  system. 

OPERATIONAL  EFFECTIVENESS 

The  overall  degree  of  mission  accom¬ 
plishment  of  a  system  used  by  represen¬ 
tative  personnel  in  the  context  of  the  or¬ 
ganization,  doctrine ,  tactics,  threat 
(including  countermeasures  and  nuclear 
threats),  and  environment  in  the  planned 
operational  employment  of  the  system. 

OPERATIONAL  REQUIREMENTS 

User  or  user  representative  generated 
validated  needs  developed  to  address 
mission  area  deficiencies.  evolving 
threats ,  emerging  technologies  or  weapon 
system  cost  improvements.  Operational 
requirements  form  the  foundation  for 
weapon  system  unique  specifications  and 
contract  requirements. 

OPERATIONAL  SUITABILITY 

The  degree  to  which  a  system  can  be 
placed  satisfactorily  in  field  use,  with 
consideration  being  given  to  availability, 
compatibility,  transportability,  interoper¬ 
ability,  reliability,  wartime  usage  rates, 
maintainability,  safety,  human  factors, 
manpower  supportability,  logistic  sup- 
portability,  and  training  requirements. 

PARTICIPATING  SERVICE 

An  organization  that  supports  the  lead 
service  in  the  development  of  a  program 
by  its  contribution  of  personnel  and/or 
funds  for  the  successful  completion  of 
the  program. 

PROGRAM  BASELINE  AGREEMENT 

A  program  baseline  document  signed  by 
the  Program  Manager  (PM),  the  Service 
Acquisition  Executive  (SAE),  and  the 
Defense  Acquisition  Executive  (DAE). 

PROGRAM  CHARTER/PROGRAM 
MANAGER  S  CHARTER 

S»e  Joint  Program  Charter/Program 
Manager's  Charier. 

PROGRAM  INSTABILITY 


The  condition  imposed  on  a  program  due 
to  problems  in  requirements,  technology, 
and  funding. 

PROGRAM  MASTER  PLAN 

A  document  developed  and  issued  by  the 
Program  Manager  which  presents  the  in¬ 
tegrated  time- phased  tasks  and  resources 
required  to  accomplish  the  tasks  speci¬ 
fied  in  th"  approved  statement  of 
need / perfo,  lance  requirements.  The 
plan  should  be  jointly  approved  for  each 
participating  service  by  persons  offi¬ 
cially  appointed  to  approve  such  plans. 

SECOND  SOURCE 

Execution  of  acquisition  strategy  to  es¬ 
tablish  two  producers  for  a  part  or  sys¬ 
tem. 

SOURCE  OF  JOINTNESS 
The  authority  that  determines  the  estab¬ 
lishment  of  a  joint  program,  be  it  inter¬ 
nal  (within  the  Service  itself)  or  external 
(by  the  OSD  or  Congress). 

STAFFING 

A  statement  of  authorized  personnel 
strength  in  a  program  office. 

SUPPORTING  SERVICE 

A  Service  designated  by  the  Secretary  of 
Defense,  or  as  the  result  of  Service  Ini¬ 
tiatives,  to  assist  the  designated  lead 
Service  in  the  management  of  a  Multi - 
service  Operational  Test  and  Evaluation 
(MOT&E)  or  Joint  Test  and  Evaluation 
(JT&E)  program. 

SYSTEM  ENGINEERING 

The  application  of  scientific  and  engi¬ 
neering  efforts  to  (1)  transform  an  op¬ 
erational  need  into  a  description  of  a 
system  configuration  which  best  satisfies 
the  operational  need  according  to  the 
measures  of  effectiveness;  (2)  integrate 
related  technical  parameters  and  assure 
compatibility  of  all  physical,  functional 
and  technical  program  interfaces  in  a 
manner  which  optimizes  the  total  system 
definition  and  design ;  (3)  integrate  the 
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efforts  of  all  engineering  disciplines  and 
specialties  into  the  total  engineering  ef¬ 
fort. 


SYSTEM  ENGINEERING  PROCESS 

The  iterative ,  logical  sequence  of  analy¬ 
sis,  design,  test  and  decision  activities 
that  transforms  an  operational  need  into 
the  descriptions  required  for  production 
and  fielding  of  all  operational  and  sup¬ 
port  system  elements. 

TAILORING  (JOINT  PROGRAMS) 

The  process  of  evaluating  potential  re¬ 
quirements  of  the  participating  services 
to  determine  their  pertinence  and  cost 
effectiveness  for  a  specific  system  or 
equipment  joint  acquisition,  and  modi¬ 
fying  these  requirements  to  ensure  that 
each  contributes  to  an  optimal  balance 
between  the  needs  of  the  participating 
services  and  cost. 

WITHDRAWAL 

The  action  taken  by  a  service  to  remove 
its  resources  of  personnel  and  funds 
from  a  Joint  Program  before  the  pro¬ 
gram  is  completed. 
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This  guide  was  prepared  as  a  reference  document  for  program  management 
personnel.  Because  of  the  dynamic  nature  of  the  entire  acquisition  environment, 
revisions  and  updates  to  this  guide  are  expected  to  be  necessary.  Your  comments 
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